Woodpecker CI 3.18 migre son stockage de logs et cesse d’exposer les variables matrix aux plugins
La version 3.18 du CI/CD auto-hébergé Woodpecker impose une migration de base qui touche le stockage des journaux — sauvegarde et fenêtre de maintenance recommandées avant de mettre à jour. Elle durcit aussi la sécurité : les variables d’environnement additionnelles et de matrice ne sont plus injectées automatiquement dans les plugins.
25 août 2026. Woodpecker CI, la plateforme de CI/CD auto-hébergée qui fonctionne avec GitHub, GitLab, Gitea et Forgejo, publie sa version 3.18. Une migration de base. C’est la première chose qu’un administrateur doit lire dans les notes de version : le stockage des logs change de structure, et la migration peut prendre du temps sur les installations chargées.
La sortie est à double visage. D’un côté, une migration de stockage qui impose une sauvegarde et une fenêtre de maintenance ; de l’autre, un resserrement de sécurité bienvenu sur ce que les plugins peuvent voir de vos secrets d’environnement.
Une migration de logs à ne pas prendre à la légère
Le changement le plus structurant de la 3.18 est invisible au premier abord. Woodpecker réorganise la façon dont il stocke les journaux de pipeline : le stockage sous-jacent impose désormais une entrée de log par ligne, avec un index unique. C’est ce qui explique la migration de base, et c’est ce qui la rend potentiellement longue sur une installation qui accumule des lignes depuis des mois.
La consigne officielle est sans ambiguïté : faire une sauvegarde avant de mettre à jour, et prévoir un temps d’arrêt supplémentaire pendant que la migration s’exécute. Sur une instance qui orchestre des dizaines de dépôts et des années de builds, la réorganisation peut représenter une vraie fenêtre de maintenance — pas un docker compose pull anodin.
En contrepartie, les logs gagnent en cohérence. Les logs d’étape sont renvoyés dans le bon ordre de lignes, et un endpoint dédié permet désormais de télécharger les journaux d’un pipeline. Pour qui a déjà dû reconstituer un build raté à partir de lignes entrelacées, c’est un gain concret de lisibilité.
Moins de variables exposées aux plugins
Le volet sécurité est le plus intéressant pour un SRE. Woodpecker resserre la gestion des variables d’environnement côté plugins : les variables additionnelles et de matrice ne sont plus injectées automatiquement.
Concrètement, un plugin de build ou de déploiement recevait jusqu’ici, par défaut, l’ensemble du contexte d’environnement de la pipeline — y compris des variables qu’il n’avait aucune raison de connaître. C’est un vecteur classique de fuite : un plugin tiers compromis, ou simplement bavard dans ses logs, pouvait exposer des secrets ou des valeurs de configuration qui ne le concernaient pas.
La nouvelle règle inverse la logique : rien n’est injecté sans le demander. C’est le principe du moindre privilège appliqué aux variables d’environnement, et c’est exactement le genre de durcissement qui compte sur un CI/CD auto-hébergé où l’on exécute du code de plugins dont on n’a pas audité chaque ligne.
Un protocole gRPC qui refuse les agents incompatibles
Woodpecker ajoute aussi un garde-fou sur la communication entre serveur et agents. Un contrôle de version de protocole gRPC empêche désormais un agent utilisant une version incompatible de se connecter au serveur.
C’est un changement discret mais utile : une flotte d’agents hétérogène — un serveur à jour, des agents restés en arrière — pouvait produire des échecs difficiles à diagnostiquer, le serveur acceptant des connexions qu’il ne comprenait qu’à moitié. Le rejet explicite des agents incompatibles rend la panne lisible : l’agent ne se connecte pas, plutôt que de se connecter et d’échouer en aval.
Les agents gagnent en résilience dans la foulée : les tentatives de reconnexion sont désormais relancées après une erreur DeadlineExceeded, en plus de la condition Unavailable déjà gérée. Sur un réseau instable, c’est une réduction des faux négatifs de connectivité.
Les autres ajustements qui comptent
Le reste de la version est une série de corrections ciblées qui dessinent une maturation progressive du produit.
- Pipelines manuelles à message personnalisé : on peut désormais attacher un contexte à un déclenchement manuel, pour documenter pourquoi ce run a été lancé.
- Noms uniques imposés pour les services et les étapes dans les pipelines DAG — fin des collisions silencieuses.
- Backend Kubernetes : option pour désactiver le réglage du nom de runtime class, et configuration du cluster domain au lieu de la valeur par défaut.
- Intégration GitLab : le chemin complet du groupe sert désormais d’identifiant, ce qui fiabilise les organisations imbriquées.
- Multi-forge : on peut configurer, pour chaque forge, quelles organisations sont autorisées à utiliser le service.
La version corrige aussi le support Windows — commande interne de décodage Base64 sur le backend local, correctif d’un bug qui empêchait plusieurs applets PowerShell de s’exécuter correctement — et met à jour une série de dépendances, du plugin Git au client Docker CLI en passant par protobuf.
Où se situe Woodpecker dans le CI/CD auto-hébergé
Woodpecker occupe une niche précise : un CI/CD léger, auto-hébergé, qui se branche sur Gitea et Forgejo là où Drone a marqué le pas et où les Actions natives de Forgejo restent plus jeunes. Sa valeur tient à la simplicité — un binaire, un agent, des pipelines en YAML — et à un modèle de plugins qui évite la complexité des runners GitLab. À la différence des grandes forges SaaS, Woodpecker laisse l’équipe propriétaire de son infrastructure de build — un choix qui prend tout son sens quand les runners doivent atteindre un réseau interne ou des secrets qu’on refuse de confier à un tiers.
La migration de stockage de la 3.18 rappelle le coût de ce choix : sur une plateforme SaaS, la migration des logs est invisible ; sur une instance auto-hébergée, c’est vous qui la portez. C’est le contrat de l’auto-hébergement, ni plus ni moins. La version le rappelle sans détour, et c’est à son honneur : mieux vaut un avertissement clair qu’une surprise en pleine nuit.
Le resserrement des variables d’environnement, lui, change concrètement le comportement des pipelines. Avant, un plugin recevait par défaut les variables de matrice et les variables additionnelles ; après, il faut les lui passer explicitement. Une pipeline qui s’appuyait sur cette injection implicite devra être revue — c’est le prix d’un défaut par défaut plus sûr.
Pour passer une variable à un plugin, il faut désormais la déclarer :
steps:
deploy:
image: woodpeckerci/plugin-docker-buildx
settings:
registry: ghcr.io
environment:
MATRIX_OS: "${MATRIX_OS}"Avant la 3.18, ${MATRIX_OS} était disponible sans cette déclaration. Le changement est volontairement strict : tout ce qu’un plugin voit doit être nommé.
Verdict
Si vous opérez un Woodpecker CI en production, traitez cette mise à jour comme une maintenance planifiée, pas comme un patch de routine. Sauvegardez la base, prévoyez une fenêtre, et vérifiez après migration que vos logs de pipeline se relisent correctement. Le bénéfice sécurité — moins de variables exposées aux plugins — vaut la fenêtre, mais il ne vaut pas de sauter la sauvegarde.
Si vous évaluez Woodpecker face à une forge SaaS, cette version illustre précisément le compromis de l’auto-hébergement : vous gagnez le contrôle et le durcissement du moindre privilège, mais vous héritez aussi de la responsabilité des migrations de stockage. C’est un choix assumé — à condition de ne jamais le découvrir au moment d’une mise à jour.
La leçon tient en une phrase : sur un CI/CD auto-hébergé, la sécurité se joue autant dans la façon dont les plugins reçoivent vos variables que dans la façon dont vous sauvegardez vos logs avant une migration.