Woodpecker CI, a lightweight, self-hosted CI/CD platform that works with popular Git services such as GitHub, GitLab, Gitea, and Forgejo, has released version 3.17.
Existing Woodpecker users should know that version 3.18 includes a database migration affecting log storage. The migration can take time on installations with many stored log lines. Because of this, administrators should create a backup before upgrading and allow extra downtime while the migration completes.
Logging receives several improvements in this release. Woodpecker now provides a dedicated endpoint for downloading pipeline logs, and step logs are returned in their proper line order. The underlying storage was changed to enforce one log entry per line with a unique index, which partly explains the database migration.
On the security side, Woodpecker 3.18 tightens how plugins handle environment variables. Additional and matrix environment variables are no longer automatically injected, reducing the information exposed to plugins.
The Kubernetes backend also gains an option allowing administrators to disable the runtime class name setting, while GitLab integration now uses the full group path as the group identifier.
Pipeline handling has received attention as well. Manually triggered pipelines can now carry a custom message, making it easier to provide some context about why a particular run was started. Woodpecker also enforces unique names for services and steps when DAG-based pipelines are used.
Another new safeguard prevents agents using an incompatible gRPC protocol version from connecting to a Woodpecker server. Agents have also become more resilient to temporary communication problems, with connection attempts now retried after DeadlineExceeded errors in addition to the previously handled Unavailable condition.
For installations connected to multiple source-code hosting services, Woodpecker 3.18 lets you configure which organizations can use the service separately for each forge. Kubernetes users can also configure the cluster domain instead of relying on the default value.
On top of that, Woodpecker now rejects invalid workflow states, sorts workflow files by name, and determines previous and latest pipelines by pipeline number rather than internal database IDs.
Windows support also gets a couple of fixes and enhancements. The local backend now includes an internal command for decoding Base64 data, while an issue preventing multiple PowerShell cmdlets from running correctly has been resolved.
Finally, the release includes numerous dependency and maintenance updates, including newer versions of Woodpecker’s Git plugin, GitLab API client, Docker CLI library, protobuf components, and various frontend packages.
For additional details, see the changelog.
