Repository navigation
v1.4.5
Pipeline generation change. Behavioural, worth reading before updating.
Only tag builds publish now
rake woodpecker generated push steps that ran rake tag and rake push, exactly like the tag steps. Two consequences:
- A tagged release commit built twice. Pushing the commit and then pushing the tag produced two pipelines for the same SHA, racing to publish identical tags.
- Every push to main moved
:latest. Anyone tracking:latestwas picking up unreleased commits, not releases.
Generated pipelines now separate the two:
| Event | Commands |
|---|---|
push, manual on main |
rake build, rake test, rake scan |
tag |
rake build, rake test, rake scan, rake tag, rake push |
Commits on main still get full CI feedback (build, test and vulnerability scan). They just do not ship. Publishing to Harbor happens on a git tag and nowhere else.
Chained builds are unaffected
depends_on only orders steps, and rake tag names the image locally in the same workspace, so a dependent build resolves its base image without anything having been pushed to a registry first.
Note for consuming repos
Run rake update && rake woodpecker and commit the regenerated .woodpecker/build.yaml.
After updating, a push to main no longer publishes anything. To ship an image you must tag it:
# bump the version in metadata.yaml first, then
git tag -a v1.2.3 -m "..."
git push origin v1.2.3Since v1.4.3 the tag is checked against metadata.yaml, so a tag that disagrees fails the pipeline rather than publishing the wrong version.
Immediately after a release, releases/latest/download/ can serve the previous asset from some CDN edges for a few minutes. If rake update appears to pull the wrong version, use CRUCIBLE_REF=v1.4.5 rake install.