Woodpecker CI, an open-source CI/CD automation platform, released version 3.20, adding new pipeline management capabilities, security improvements, faster scheduling, and fixes that improve server stability and integrations.
One main addition is the ability to select a specific workflow when manually triggering a pipeline. Previously, users couldn’t choose individual workflows during manual pipeline execution.
Another notable change adds an option to restrict organizations and users to their own agents, giving administrators more control over which agents execute pipelines, especially in environments where multiple organizations share the same Woodpecker instance.
Regarding security, agent tokens have been removed from process environments, while bearer credentials are no longer written to trace-level logs. Additionally, repository JWTs are now rotated during repository repair operations, and configuration fetching has been hardened.
Further improvements strengthen access controls when retrieving organization-level secrets and registry credentials. If permission synchronization with a connected Git hosting service fails, Woodpecker now falls back to read-only access instead of potentially granting broader permissions.
On the performance side, version 3.20 speeds up queue scheduling calculations and ensures a paused queue stays paused after a server restart.
The update also introduces a new CI_REPO_ID environment variable, making the repository identifier available within pipelines. Plus, the CLI lint command now prefers automatically detected Woodpecker configuration files, simplifying configuration validation.
For the web UI, the developers have reworked the dark theme, added an indication when permission fallback occurs, and improved the consistency of collapsible workflow sections.
Regarding bug fixes, Woodpecker CI 3.20 addresses several server crashes related to configuration parsing and workflow storage. It also fixes an issue where workflows using depends_on could run despite a failed dependency after the execution queue was reloaded.
Kubernetes backend reliability has also improved: deleted pods with an unknown status are no longer incorrectly reported as successful, and backend configuration parsing now returns an error when it encounters invalid options.
Git hosting integrations receive several corrections. GitLab now handles group-inherited repository permissions more accurately, while annotated tag commit resolution has been fixed for GitLab, Gitea, and Forgejo. The release also addresses OAuth token refreshing across GitHub, GitLab, Gitea, and Forgejo.
Other fixes cover Docker backend connections using TLS with custom hosts, SQLite database locking during pipeline creation, agent keepalive and timeout handling, and scheduled pipelines created without an explicit enabled field.
Finally, users should note that the original 3.20.0 release contains an unintended breaking change. The developers have published version 3.20.1, restoring the affected drone/envsubst functionality and correcting a step log grouping issue in the web interface.
For more information, see the changelog.
