Woodpecker CI frente a GitHub Actions: secretos y salida
Una guía para decidir dónde correr pipelines, cómo guardar secretos, qué runner toca producción y cómo probar la salida antes de depender de una cuenta externa.
Un archivo .woodpecker.yaml decide qué código se compila, qué secreto entra al runner y quién puede mirar el log. En la encuesta Stack Overflow 2025, 35,43 % de quienes respondieron dijo usar entre 6 y 10 herramientas de trabajo; la automatización dispersa agranda ese número. Esta guía compara Woodpecker CI y GitHub Actions para elegir por secretos, runners, registros y salida.
La decisión aparece cuando el runner toca datos reales
El dolor operativo nace cuando el pipeline deja de compilar una web de prueba y empieza a publicar artefactos, migrar bases o firmar imágenes. El token pegado en variables globales parece cómodo hasta qué aparece en un log o queda activo después de la salida de un proveedor. Woodpecker documenta tres niveles de secretos: repositorio, organización y global; el último queda disponible para toda la instancia y exige cuidado. GitHub Actions resuelve gran parte del flujo desde el SaaS: secretos por repositorio, organización y entorno, runners hospedados y runners propios. Woodpecker 3.18.x, según su documentación, trabaja con workflows que comparten un workspace y pasos ejecutados en secuencia. La pregunta operativa es concreta: dónde vive el secreto, qué runner puede leerlo y quién puede apagarlo un viernes a las 18. Un sticker con la leyenda "deploy-prod" en una notebook ThinkPad vieja resume la escena social de muchas pymes. El equipo sabe cuál máquina publica, pero el permiso vive en una cuenta personal o en una variable que nadie revisó desde la primera instalación. El dato qué conviene separar desde el primer día es el alcance. Un secreto de lectura para instalar dependencias, un secreto de escritura para publicar imagen y un secreto de despliegue para producción tienen dueños distintos. Si se guardan juntos, la auditoría llega tarde. Si se nombran con ambiente, responsable y vencimiento, el equipo puede retirar uno sin frenar todos los pipelines.
Cómo funciona por dentro
El flujo correcto tiene seis pasos. Primero, el repositorio recibe un archivo de workflow que separa prueba, build y deploy. Segundo, el servidor de CI lee el cambio y crea una ejecución. Tercero, el runner toma la tarea en una red definida y monta el workspace con el código. Cuarto, el secreto llega al paso mediante una variable acotada, por ejemplo from_secret en Woodpecker. Quinto, el artefacto queda en un registro de contenedores o en un servidor de despliegue. Sexto, el log guarda commit, usuario, hora, resultado y duración. La base guarda repositorios, usuarios, permisos y estados de ejecución. El backup conserva configuración del servidor, base de datos, secretos cifrados si la herramienta los permite y archivos de workflow del repositorio. Woodpecker recibe eventos del repositorio y entrega ejecuciones sobre runners propios. GitHub Actions recibe eventos dentro de GitHub y entrega jobs sobre runners de GitHub o propios. La diferencia práctica aparece en la red: un runner local puede llegar a una VPN interna; un runner hospedado necesita permisos más abiertos o un canal controlado. ## Qué se instala o configura primero Para Woodpecker, la pila mínima es un servidor con base, un runner Docker aislado, conexión al proveedor Git, registro de contenedores y backup. Un VPS de control, un segundo host para runner y almacenamiento de copias cuesta cerca de USD 80 mensuales, unos $ 122.400 con dólar vendedor de $ 1.530. El costo no incluye horas de armado ni hardening de red. Para GitHub Actions, el costo inicial puede ser menor si el uso entra en minutos incluidos y no se necesita red privada. El primer entregable verificable es una ejecución que corre tests, construye imagen, firma versión y falla si falta un secreto. La prueba debe incluir rotación: cambiar un token y comprobar que el deploy anterior queda sin acceso. UMSA suele recomendar una matriz breve antes de instalar: repositorios críticos, secretos usados, destino de deploy, responsable de aprobación y plan de salida. Si la empresa tiene datos productivos detrás de VPN, Woodpecker con runner propio da control de red. Si el equipo ya trabaja en GitHub y publica artefactos públicos, Actions reduce administración diaria.
Dónde se rompe y cómo probarlo
El primer riesgo es el secreto demasiado amplio. La señal aparece cuando el mismo token publica en staging y producción. La prueba crea dos entornos y confirma que el token de prueba no puede escribir en producción. El segundo riesgo es el runner compartido. La señal aparece cuando jobs de clientes distintos usan la misma carpeta, cache o usuario de sistema. La prueba borra el workspace, corre dos pipelines consecutivos y revisa que el segundo no lea archivos del primero. El tercer riesgo es la salida mal escrita. La señal aparece cuando el equipo no puede reproducir un deploy fuera de la plataforma. La prueba mínima exporta workflows, lista secretos por nombre, documenta runners y ejecuta un pipeline local o en una instancia de reemplazo. El CI que no se puede apagar ordenadamente manda más que el equipo.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.