Skip to content

v1.4.5

Choose a tag to compare

@jweisner jweisner released this 28 Sep 21:19
· 5 commits to master since this release

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:

  1. 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.
  2. Every push to main moved :latest. Anyone tracking :latest was 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.3

Since 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.