Woodpecker CI 3.18: runners, secretos y logs
Woodpecker CI 3.18 cambia almacenamiento de logs. Qué revisar en runners, secretos, backups y despliegues antes de actualizar producción sin perder historial.
Woodpecker CI publicó la versión 3.18.0 el 24 de agosto de 2026 y avisó que la migración cambia el almacenamiento de logs. Para una pyme con repositorios internos, runners y despliegues nocturnos, el detalle pesa más que la versión: una actualización sin backup puede dejar historial incompleto o agentes parados. Esta guía muestra qué revisar antes de tocar producción y qué prueba marca salida. ## Qué cambia cuando el log también es evidencia La API de GitHub Releases informa v3.18.0 como última versión publicada y el aviso de migración pide backup y tiempo extra de parada. Ese dato corrige una lectura habitual: el log de CI no es basura técnica. En talleres, estudios contables y fábricas con software interno, el historial de una tarea prueba quién desplegó, qué commit salió, qué secreto se usó y por qué se detuvo una entrega. El log también es evidencia. La documentación de plataformas soportadas separa servidor, agente, CLI y plugin Git. El servidor administra interfaz, API, webhooks y planificación; el agente ejecuta flujos con Docker, Kubernetes o ejecución local. La guía de Docker Compose permite levantar componentes con variables y archivo de entorno, aunque avisa que esa práctica exige cuidado. Para un encargado de sistemas de fábrica metalmecánica en San Martín, esa separación define permisos, mantenimiento y guardia. La encuesta 2025 de Stack Overflow ubica a Git entre las herramientas más usadas por desarrolladores profesionales. La cifra no convierte a toda pyme en software factory; muestra que repositorio, rama y despliegue ya entraron en operaciones pequeñas. El antagonista concreto es el script nocturno que compila, copia archivos y reinicia servicios sin historial suficiente.
Cómo funciona por dentro
El flujo mínimo tiene seis piezas. Primero, el repositorio recibe un commit o tag. Segundo, Woodpecker toma el webhook y evalúa el archivo de workflow. Tercero, el servidor asigna trabajo a un agente disponible. Cuarto, el agente ejecuta pasos en orden, con contenedores o entorno local según configuración. Quinto, cada paso escribe logs y devuelve éxito o falla. Sexto, el servidor conserva estado, artefactos permitidos y resultado visible para revisión. La sintaxis de workflow ordena pasos, comandos, dependencias y condiciones. La documentación de secretos separa valores sensibles de la definición del flujo. En una instalación cuidada, el pipeline no guarda claves en YAML, los runners no comparten permisos de producción sin necesidad y cada repositorio tiene alcance definido. Si falla un paso, la salida debe mostrar comando, tiempo, agente y error sin revelar credenciales. El backup no termina en una copia de la base. También debe cubrir configuración del servidor, tokens de integración, secretos recreables, workflows, volumen de logs y procedimiento de arranque. La prueba de restauración levanta un servidor aislado, importa datos, ejecuta un pipeline de ensayo y confirma que un usuario de lectura no puede cambiar secretos. Sin esa prueba, una migración de logs se vuelve apuesta.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería un inventario de repositorios, agentes, secretos y tareas críticas. Cada fila debe decir sistema, responsable, frecuencia, entorno, secreto usado, permiso del runner, política de retención de logs y salida esperada. Después se arma un pipeline piloto con build, test, paquete, despliegue a prueba y rollback documentado. La pila inicial puede quedar en Woodpecker server, uno o dos agentes Docker, proxy TLS, base persistente, backup diario, alerta de tareas fallidas y revisión semanal de secretos. Para una pyme con tres repositorios y despliegues internos, servidor y monitoreo pueden ubicarse entre USD 25 y USD 60 mensuales, entre $38.375 y $92.100 al dólar oficial vendedor de $1535. La implementación inicial puede ir de USD 900 a USD 1.500, entre $1.381.500 y $2.302.500. Ese rango no incluye reescritura de aplicaciones, licencias externas ni guardia permanente.
Dónde se rompe y cómo probarlo
El primer riesgo está en un agente con demasiados permisos. La señal aparece cuando un runner de pruebas puede desplegar producción. La prueba crea dos agentes, fuerza una tarea sensible desde el repositorio equivocado y guarda el rechazo. El segundo riesgo es un secreto expuesto por log. La señal aparece cuando una variable queda impresa en una falla. La prueba ejecuta un pipeline de ensayo con secreto falso, provoca error y revisa salida completa. Si el valor aparece, el flujo debe cambiar antes de publicar. El tercer riesgo es migrar sin restauración medida. La señal aparece cuando el backup existe, pero nadie sabe cuánto tarda volver. La prueba toma una copia, levanta servicio en otro host, corre un workflow y exporta logs anteriores. El acta necesita hora de inicio, hora de fin, usuario, comando y evidencia de lectura. La decisión técnica debería cerrarse con un reporte de runners activos, secretos por repositorio, últimos fallos, pipelines sin dueño y tamaño de logs. Ese reporte no pide mirar todos los builds; obliga a revisar los puntos que cortan una operación. Si la fábrica usa CI para facturación, integración con balanzas o publicación de listas, el historial ya forma parte de la evidencia de trabajo.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.