v1.4.7

One feature, one cosmetic fix. No breaking changes; nothing runs differently until you create a cron.

Scheduled rebuilds: cron named rebuild

rake woodpecker now generates a rebuild-<version>-<variant> step per image, triggered by a Woodpecker cron named rebuild. It runs after render (so each run gets a fresh build ID) and does rake build test scan tag push with VERSION from metadata.yaml. Base-image and package fixes ship without a commit or a new git tag.

The steps filter on the cron name, so they are inert until you add the cron:

woodpecker-cli repo cron add --repo ORG/REPO --name rebuild --branch main --schedule '0 11 * * *'

Schedules are standard 5-field cron, UTC. Each run publishes a new b<id> tag and moves floating tags (latest, version tags, git_sha tags) to the rebuilt image.

No more YAML anchors in the generated pipeline

The generated .woodpecker/build.yaml no longer contains &1/*1 aliases for repeated when/environment blocks.

Note for consuming repos

Run rake update && rake woodpecker and commit the regenerated .woodpecker/build.yaml. If rake update pulls a stale copy from the CDN, use CRUCIBLE_REF=v1.4.7 rake install.

v1.4.6

One fix, one install fix, one opt-in feature. No breaking changes.

Unversioned images publish again (on a git tag)

v1.4.5 made tag steps the only publishers, but generated them only for images with a version. A repo with no versions: key (e.g. container-wolfi-base, published as :latest only) got a pipeline with no rake push anywhere: every build green, nothing reaching the registry.

Unversioned images now get a tag-<variant> step without the VERSION export, so any git tag publishes them. Versioned images are unchanged.

If you are on v1.4.5 with an unversioned repo, run rake update && rake woodpecker and commit the regenerated .woodpecker/build.yaml.

CRUCIBLE_REF install fixes

• No longer crashes when lib/ is missing (it called String#green, which lives in lib/).
• Finds the extracted archive directory instead of predicting it, so short SHAs work, and checks it before removing the existing lib/. Previously a mismatch deleted lib/ and left nothing in its place.

git_sha for commit-SHA image tags (opt-in)

git_sha returns the 7-character commit SHA (Woodpecker's CI_COMMIT_SHA, else the local checkout) for use in ERB tags:

tags:
  - 'latest'                                       # tags: replaces the default, so restate latest
  - '<%= tag_join(version, variant, git_sha) %>'

Default tags are unchanged.

Note

releases/latest/download/ can serve the previous asset from some CDN edges for a few minutes. If rake update pulls the wrong version, use CRUCIBLE_REF=v1.4.6 rake install.

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:

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.

v1.4.4

One dependency bump. No breaking changes.

Default dockerize bumped 0.13.0 → 0.15.1

dockerize 0.13.0 carries nine HIGH Go stdlib CVEs compiled into the binary (net/http, crypto/tls, encoding/xml, net/url, html/template, golang.org/x/net/idna). Any image built on the crucible default therefore failed rake scan on the dockerize binary alone, even with a completely clean Alpine package set.

Measured on container-keepalived:

                            0.13.0              0.15.1
alpine                      0                   0
usr/local/bin/dockerize     9 HIGH              0
rake scan                   exit 1              exit 0

Templating behaviour is unchanged: verified by rendering a keepalived.conf and passing keepalived --config-test.

Why this is only surfacing now

This is a pre-existing condition, not a regression. Repos with hand-written pipelines frequently omitted rake scan; the generated pipeline from v1.4.3 includes it, so the finding became visible on the first generated build. Images built before this have been carrying these CVEs all along.

tini, catatonit and container-entrypoint were checked at the same time and are already at their latest upstream releases. dockerize was the only stale pin.

Note for consuming repos

Run rake update && rake template and rebuild. A repo pinning dockerize_version in its own metadata.yaml vars: overrides this default and needs bumping separately.

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.4 rake install.

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.

v1.4.2

Two bug fixes. No new features, no breaking changes.

rake scan now works where trivy has no container runtime socket

Trivy was handed a bare image reference. It resolves local images through a runtime socket, and there is none inside the woodpecker-crucible container — on rootless podman it also probes a relative podman/podman.sock and so misses $XDG_RUNTIME_DIR/podman/podman.sock. With no socket it fell through to its remote resolver and tried to pull the digest from Docker Hub:

unable to find the specified image "sha256:..." in [docker containerd podman remote]
remote error: GET https://index.docker.io/v2/library/sha256/manifests/...
UNAUTHORIZED: authentication required

The task now exports the image with podman save --format docker-archive and scans it with --input. No socket, no registry, no auth. Passing a tag instead of the digest does not help — the problem is the missing socket, not the reference format.

This went unnoticed because the older hand-written pipelines never ran rake scan; the rake woodpecker generator added the step and exposed it.

A VERSION/VARIANT filter matching no image now fails

$images.select! silently emptied the list, and every task then iterated nothing and exited 0: rake build built none, rake tag tagged none, rake push pushed none. A completely green pipeline that produced no artifact.

This was hit after renaming a version key in metadata.yaml while the committed .woodpecker/build.yaml still passed the old VERSION. The pipeline went green in six seconds and the problem only surfaced when a downstream deploy could not pull an image that had never been published.

An empty filter result now aborts, listing the versions and variants that do exist and pointing at rake woodpecker to regenerate a stale pipeline. The guard sits at the filter, so it covers every task at once.

Upgrading

rake update && rake template

Repos carrying a local/tasks/scan.rake override for the first bug can drop it after upgrading.

v1.4.1

Fix ce_version default to match the actual container-entrypoint release tag.

The container-entrypoint snippet builds its download URL as v<ce_version>, but the default was 1.0 while the only published release tag is v1.0.0. Builds using the snippet without an explicit ce_version got a 404. Default is now 1.0.0.

v1.4.0

What's new

• Parallel CI builds: rake woodpecker renders .woodpecker/build.yaml from the image matrix, producing one parallel Woodpecker step per version×variant
• VERSION/VARIANT filtering: set VERSION=17 and/or VARIANT=pgvector to restrict any rake task to a subset of the matrix — works locally and in CI
• depends_on variant key: declare variant build ordering in metadata.yaml so rake woodpecker can wire Woodpecker depends_on correctly (e.g. pgvector waits for base to be pushed first)
• CRUCIBLE_REF support: CRUCIBLE_REF=main rake install installs lib/ and the Rakefile from a specific branch or tag instead of the latest release — useful for testing before cutting a release
• Fix stale dockerize_version default in README (0.11.1 → 0.13.0)

v1.3.7

Bump dockerize default version to 0.13.0

v1.3.6

Changes

• Fix container-entrypoint.sh missing execute permission; the tarball ships the script as rw-r--r-- so chmod 0555 is now applied explicitly after extraction