v1.4.3

One feature. No breaking changes.

rake woodpecker now generates a tag step that checks the git tag against metadata.yaml

rake woodpecker emitted only push/manual steps, so a repo that wanted to build on a git tag had to hand-write that step, and regenerating the pipeline silently dropped it. Hand-written tag steps also tended to duplicate the push step exactly, because nothing passed the tag into the build. Tagging was effectively a no-op that republished whatever version metadata.yaml happened to hold.

The generated tag step derives VERSION from CI_COMMIT_TAG:

- name: tag-1.2.0-base
  when:
  - event: tag
  commands:
  - export VERSION="${CI_COMMIT_TAG#v}"
  - rake install / template / build / test / scan / tag / push

Combined with the VERSION filter added in v1.4.2, which aborts when it matches no image, the git tag and metadata.yaml now check each other. Tagging v1.2.0 while metadata.yaml still says 1.1.0 fails the pipeline:

No image in metadata.yaml matches VERSION=1.2.0.
Available:
  VERSION=1.1.0 VARIANT=(none)

rather than quietly rebuilding and republishing 1.1.0. That closes the gap where the "bump metadata.yaml, then git tag to match" procedure relied entirely on the operator remembering both steps.

A leading v is stripped, so v1.2.0 and 1.2.0 both work.

Repos with no versions: key get no tag step, since there would be nothing for a tag to agree with; an unversioned metadata.yaml still generates only render and build-base.

Note for consuming repos

Run rake update && rake woodpecker to pick this up, then commit the regenerated .woodpecker/build.yaml. A repo with a hand-written pipeline will have it replaced.