Tags

Tags give the ability to mark specific points in history as being important

  • 2.2.3

    d77def3f · fix(2.2.3): yq install via pip (python3-yq not in Fedora 42) ·
    Release: pipeline 2.2.3 
    2.2.3 — fix ci image build that failed under 2.2.2

Same intent as 2.2.2 (bake yq/tomlq into the ci image for consumers
of dunn.dev/reference that exercise check_toml_key). The 2.2.2
attempt used a non-existent Fedora 42 package and the image build
failed. 2.2.3 switches to pip install yq with PEP-668 override.

  • 2.2.2

    53a7e5ff · fix(2.2.2): add python3-yq to ci image for tomlq primitive · 
    2.2.2 — yq/tomlq in ci image

Bakes python3-yq (kislyuk variant) into the ci image so consumers
of dunn.dev/reference can run contracts whose check.sh uses the
check_toml_key primitive.

Image grows ~25 MB. No template changes; reference-check@2.2.2 and
all other components consume ci:2.2.2 the same way they did at 2.2.1.

  • 2.2.1

    d1f57eb1 · fix(2.2.1): reference-check accepts arbitrary git refs ·
    Release: pipeline 2.2.1 
    pipeline 2.2.1

Patch: reference-check accepts arbitrary git refs (SHA, branch, tag).
The 2.2.0 release used git clone --branch which rejects SHA refs,
breaking the canonical dog-food pattern of reference_ref:
$CI_COMMIT_SHA. Fix replaces the clone with init + remote add +
fetch <ref> + checkout FETCH_HEAD.

  • 2.2.0

    3f6286a3 · feat(runner): catalog is runner-agnostic from 2.2.0 ·
    Release: pipeline 2.2.0 
    pipeline 2.2.0

New component for dunn.dev/reference conformance plus catalog runner
relaxation.

ADDED
- reference-check component: clones gitlab.com/dunn.dev/reference at a
  configurable ref (default main), runs 'make guard' to enforce the
  six-primitive whitelist, then runs 'make check REPO=$CI_PROJECT_DIR'
  to verify the consumer against every applicable contract. Single
  exit code answers the operator question 'does this repo conform'.
  Inputs: reference_ref, reference_url, fail_on_violation, job_name.

CHANGED
- Every template + meta-CI: drop 'tags: [storr]'. The catalog is
  runner-agnostic from 2.2.0 onward; consumers opt into larger runner
  classes at the project level. The v2.0.0 'all jobs run on storr'
  contract clause is hereby relaxed.

CI image
- ci:2.2.0 is built on this tag push by the catalog's meta-CI
  container:ci job. Contents unchanged from 2.1.2 (yq/tomlq not yet
  added; planned for 2.2.1 when the reference's web-deploy contract
  ships and starts using check_toml_key).

  • 2.1.2

    df3c7285 · fix(2.1.2): release-title rendering + cloudflare-worker overhaul ·
    Release: pipeline 2.1.2 
    2.1.2 - release-title fix + cloudflare-worker overhaul

release-create: drop the recursive component-input default that
rendered release titles as the literal string
'$\[\[ inputs.package_name \]\] v0.1.0'. Title is now constructed
in-script from package_name + CI_COMMIT_TAG when the input is empty.

cloudflare-worker: canonical static-site deploy surface with
feature parity over cloudflare-pages plus Web Analytics auto-inject.
New inputs: build_command, output_dir, needs_npm_install, npm_dir,
web_analytics_token, production_url. Build + deploy-worker split.

cloudflare-pages: marked deprecated. Migration path to
cloudflare-worker is documented in CHANGELOG.md.

  • 2.1.1

    ad59eaf7 · fix(2.1.1): append .exe on go-build + go-release-binary for windows targets ·
    Release: pipeline 2.1.1 
    2.1.1 - .exe handling for windows targets in go-build + go-release-binary

go build only auto-appends .exe when -o is unset. The catalog templates
always pass -o explicitly, so consumers adding windows/amd64 produced
an extension-less binary that's unrunnable on Windows without manual
rename. Both templates now append .exe when GOOS=windows.

No template inputs change. Consumers on 2.1.0 can bump to 2.1.1 with
no other edits.

  • 2.1.0

    98661598 · fix: ci-rust cargo-zigbuild smoke check invocation ·
    Release: pipeline 2.1.0 
    2.1.0 - self-contained Rust supply chain

Adds rust-lint, rust-release-binary, rust-sbom, rust-crates-publish
templates so a Rust CLI consumer can ship a fully-signed, cross-
compiled release through the dunn.dev catalog without depending on
any external catalog.

ci-rust image expanded: Rust 1.95 base, clippy + rustfmt rustup
components, standalone zig 0.13.0, cargo-zigbuild 0.22.2,
aarch64-apple-darwin and aarch64-unknown-linux-gnu rustup targets,
Phracker MacOSX 11.3 SDK mounted at /opt with SDKROOT exported.

Cross-compile picks zig-as-linker for darwin/arm64 + linux/arm64
(no nested docker required; one image, one toolchain). linux/amd64
is plain cargo build. parallel:matrix shape mirrors go-release-binary.

The supply-chain components (slsa-attest, release-create,
container-image) are language-agnostic and compose with
rust-release-binary the same as with go-release-binary.

See CHANGELOG.md for the full migration shape and consumer example.

  • 2.0.3

    6d99f964 · fix(2.0.3): cosign login before signing container image ·
    Release: pipeline 2.0.3 
    2.0.3 - cosign auth fix for container-image signing

container-image template: cosign now does an explicit registry
login before signing the pushed image. buildah and cosign use
different auth conventions (podman auth.json vs docker
config.json), so the buildah login from before_script was not
visible to cosign. Bairn v0.5.0 hit this; the cli image was
pushed unsigned.

No template inputs change. Consumers on 2.0.2 can bump to 2.0.3
with no other edits.

  • 2.0.2

    0abd3e28 · fix(2.0.2): container-image rules + release description from file ·
    Release: pipeline 2.0.2 
    2.0.2 - container-image rule + release tooling fixes

container-image template: when from_artifacts is enabled, the rule
now only fires on tag pipelines. Prior versions fired on main +
Containerfile-changed too, which has no upstream dist/ to COPY
from. Bairn v0.5.0 worked around it with a consumer-side rules
override; future consumers do not need the override.

release-cli step in the catalog meta-pipeline now reads the tag
annotation from a file (release-description.md) instead of a shell-
substituted variable. This avoids the release-cli image evaluating
shell-active text in tag annotations (the 2.0.1 release job died
when the annotation contained component-context syntax).

No template inputs change. Consumers on 2.0.1 can bump straight
to 2.0.2 with no other edits and (if they used the bairn-style
override) drop their build-image rules override.

  • 2.0.1

    f96eadc2 · fix: hardcode :$[[ component.version ]] image in job body, drop image input ·
    Release: pipeline 2.0.1 
    2.0.1 — image interpolation fix

CRITICAL fix to v2.0.0's tooling-pinning premise. GitLab single-pass
interpolation does NOT recursively resolve $[[ component.version ]]
inside input default strings. The 2.0.0 templates put the version
interpolation inside the image: input default, which produced a
literal "ci-go:$[[ component.version ]]" string at consumer pipeline
runtime, breaking image pulls.

Fix: dropped the `image:` input from every template; image: now lives
in the job body where composition-time interpolation works correctly.

Consumers who previously overrode `image:` via component input must
now use `extends:` to override the job's image directly. None of the
estate consumers used the input override.

Also fixes catalog test-include suppression to add allow_failure: true
so future tag pipelines don't block on manual upstreams (2.0.0 release
was published via API as a one-time recovery).

Migration from 2.0.0:
- Bump @2.0.0 to @2.0.1 in your .gitlab-ci.yml
- If you passed an `image:` input to any go-*/rust-*/cloudflare-*
  component, drop that input. To override, use `extends:`.

  • 2.0.0

    8a2f4760 · fix: catalog test include — override included rules: to suppress matrix ·
    Release: pipeline 2.0.0 
    2.0.0 — catalog overhaul

Switches the catalog onto current GitLab CI idioms. Backward
incompatible against v1.x consumer overrides; v1.x consumers stay
on @v1.x until ready to migrate.

Highlights:
- spec:component + $[[ component.version ]] image pinning (true
  tooling coupling; no more silent :latest drift)
- new go-lint template (replaces docker.io/golangci-lint pull cap +
  allow_failure pattern)
- new ci-runtime-go runtime image (UBI micro 9.6) for Go CLI
  release containers via from_artifacts mode
- container-image: from_artifacts (byte-for-byte parity with signed
  binary), multi_arch (amd64+arm64 manifest list), sign_image
  (cosign by registry digest, --recursive for manifest lists),
  binfmt preflight check, BUILDAH_FORMAT=oci default
- go-build + go-release-binary: parallel:matrix cross-compile
  (linux/amd64, linux/arm64, darwin/arm64), per-target Go module
  cache, per-binary .sha256 sidecars
- input validation: regex on cosign_version, syft_version,
  golangci_lint version, image_tag, model name
- workflow:auto_cancel guidance; interruptible:true on build jobs,
  interruptible:false on release-stage jobs
- catalog meta-pipeline now publishes ci-go/ci-rust/ci-runtime-go/ci
  at :\$CI_COMMIT_TAG on every catalog tag
- ci-go and ci-rust Containerfiles pull FROM mirror.gcr.io
- renovate.json gains customManager regex for ARG version pins
- README backfilled with go-* and rust-* sections; recommended
  consumer pipeline shape
- CHANGELOG.md (new) in Keep a Changelog format

Tag convention: v1.x stays v-prefixed (frozen historical records);
2.0.0+ is unprefixed strict semver per GitLab catalog convention.

See CHANGELOG.md for full migration guide.

  • v1.8.0

    00412a7f · feat: container-image supports tag-driven CLI image pattern ·
    Release: pipeline v1.8.0 
    v1.8.0 - container-image supports tag-driven CLI image pattern

Adds tag_pipeline boolean input to the container-image template.
When true, the build job also fires on $CI_COMMIT_TAG and tags the
image with the version (alongside :latest). Passes VERSION into the
Containerfile via --build-arg so multi-stage builds can stamp it
into the binary's ldflags.

CLI consumers (bairn, future Go/Rust binaries) consume this with
tag_pipeline: true; their existing latest-on-Containerfile-change
behavior is unchanged. Catalog's own ci/ci-go/ci-rust images use
the default tag_pipeline: false and behave exactly as in v1.7.0.

Backwards-compatible.

  • v1.7.0

    3698a767 · fix: ci-rust base rust:1.84 -> 1.85 (cargo-audit 0.22 requires rustc 1.85+) ·
    Release: pipeline v1.7.0 
    v1.7.0 - ci-rust pre-baked image + rust-build + rust-audit templates

Second per-language pre-baked builder image. Mirrors ci-go's
structure: rust:1.85 + cargo-audit + syft + cosign. Authenticated
pull from registry.gitlab.com.

New templates:
- rust-build: branch verification (cargo build + cargo test);
  caches target/ and .cargo/registry between jobs.
- rust-audit: cargo-audit at lint stage; allow_failure (vuln DB
  changes don't block release).

slsa-attest, release-create, and the syft-based SBOM template are
already tech-agnostic and compose with rust-build for tag releases.
A rust-release-binary template will land when patinate (or another
Rust consumer) needs durable binary publishing.

Catalog .gitlab-ci.yml grew a container:ci-rust job (mirrors
container:ci-go) and includes the new rust-* templates for
syntax validation.

Patinate is the reference Rust consumer; bumps in a follow-on commit.

ci-node and a node-build template not added: the existing `ci`
image (Fedora + node + wrangler + aws-cli) already serves the
catalog's Astro consumers via cloudflare-pages. Node templates can
land later if a non-CF-Pages Node consumer materializes.

  • v1.6.0

    bb11a862 · feat: Go templates default to ci-go image ·
    Release: pipeline v1.6.0 
    v1.6.0 - ci-go pre-baked image; Go templates flipped from mirror.gcr.io

First of the per-language pre-baked builder images. Replaces v1.5.3's
mirror.gcr.io stopgap with an authenticated pull from
registry.gitlab.com/dunn.dev/pipeline/ci-go:latest, eliminating the
docker.io unauthenticated pull rate cap that bit bairn's v0.3.0 tag
pipeline twice.

ci-go bundles: golang:1.25 + govulncheck + syft 1.32.0 + cosign 2.6.3.
Tools pinned in containers/ci-go.Containerfile (single source of
truth for versions).

Catalog .gitlab-ci.yml grew a .container-build extends-target so
ci-rust / ci-node / ci-py can land in upcoming minor releases without
copy-paste churn.

Templates affected:
- go-build, go-release-binary, go-audit, go-sbom, slsa-attest

Each template's tool install block is now \`command -v <tool> ||
install\` so consumers overriding \`image\` (e.g. with vanilla golang
or alpine) still get a working pipeline.

Backwards-compatible. Consumers using v1.5.x explicit \`image\` inputs
keep their override; consumers on defaults silently switch to the
faster, authenticated pull.

Catalog v2.0 (TBD) may collapse the per-action templates into a
single \`ci-<lang>\` swiss-army template; until then per-action stays.

  • v1.5.3

    17832301 · fix: pull base images via mirror.gcr.io (docker.io rate cap) ·
    Release: pipeline v1.5.3 
    v1.5.3 - default base images via mirror.gcr.io

Fixes a runner-side reliability issue: the storr runner is
unauthenticated to docker.io and tag pipelines that fan out across
multiple Go template jobs hit the per-IP unauthenticated pull cap
(toomanyrequests). All Go templates default to mirror.gcr.io/library/
golang now; go-sbom + slsa-attest default to mirror.gcr.io/library/
alpine. Both expose 'image' as an input for consumers to override.

API-compatible patch release. Consumers that pinned an image input
keep their pinned image.

  • v1.5.2

    b3bf980b · fix(release-create): upsert release record + asset links ·
    Release: pipeline v1.5.2 
    v1.5.2 - release-create upserts on every fire

create-release and upload-release-assets now PUT-or-POST so
every pipeline run converges the release record + asset links to
the current intent. Replaces v1.5.1's skip-if-exists behavior,
which left the release page stuck on the first pipeline's values
when a re-tag or rerun carried new content.

No other component changes.

  • v1.5.1

    18f551ec · fix(release-create): idempotent on duplicate-pipeline-fire ·
    Release: pipeline v1.5.1 
    v1.5.1 - release-create idempotent on duplicate-pipeline-fire

Single fix: release-create no longer fails when a tag's release
already exists. Replaces the GitLab CI release: keyword (which
always invokes release-cli with --no-update) with a script that
checks the API for an existing release and skips create when one
is present. upload-release-assets similarly tolerates pre-existing
asset links: 400/409 responses with "already exists" or
"has already been taken" downgrade to "already linked" instead of
failing the job.

Caught during dunn.dev/bairn v0.2.2 release: a manual API trigger
and a delayed auto-trigger raced; the second pipeline failed at
"Release v0.2.2 already exists." Cosmetic but annoying. With this
fix, future duplicate fires complete silently as no-ops.

Both jobs now use registry.gitlab.com/dunn.dev/pipeline/ci:latest
(curl + jq + bash) which matches the rest of the catalog.

No other component changes.

  • v1.5.0

    933b6db0 · feat: full supply-chain components (audit, sbom, slsa-attest) ·
    Release: pipeline v1.5.0 
    v1.5.0

Full supply-chain components for Go projects:

- go-audit: lint-stage govulncheck. allow_failure: true.
- go-sbom: tag-only CycloneDX SBOM per binary via syft.
- slsa-attest: tag-only SLSA v1.0 provenance per binary,
  keyless-signed via cosign + GitLab OIDC. Predicate field set
  matches public-sector-tools' attest template; verify with
  cosign verify-blob-attestation --type slsaprovenance1 or
  slsa-verifier.
- release-create: updated to link SBOMs and SLSA bundles
  alongside binaries on the GitLab Release page.

Combined with v1.4.0's go-build, go-release-binary, and the
existing release-create, any Go project in the dunn.dev estate
can now compose a full branch-and-tag CI from catalog includes:
audit + build on branches; package + sbom + attest + release on
tags.

First consumer: dunn.dev/bairn at v0.1.0.

  • v1.4.0

    a8fc49b0 · feat: Go components (go-build, go-release-binary, release-create) ·
    Release: pipeline v1.4.0 
    v1.4.0

Three Go-focused components:

- go-build: branch verification cross-compile (matrix of
  GOOS/GOARCH, version-from-ref ldflags). Skipped on tags.
- go-release-binary: tag-only build, sha256 checksums, cosign
  keyless signing via GitLab OIDC, upload to the project's
  generic package registry.
- release-create: tag-only GitLab Release creation with annotated
  tag message + asset linking from the package registry.

Together these enable a full branch-and-tag CI shape for any Go
project in the dunn.dev estate. First consumer: dunn.dev/bairn.

Modeled on the binary + release templates in
gitlab.com/gitlab-com/public-sector-tools/pipeline (Apache 2),
scaled down to the dunn.dev estate's needs (no SBOM, no SLSA
attestation; those layer on later if a project needs them).

Existing components (claude-drift-triage, cloudflare-pages,
cloudflare-r2, cloudflare-worker, container-image) ship at v1.4.0
unchanged.

  • v1.3.0

    0d04dfaf · feat: claude-drift-triage component for LLM-augmented CI ·
    Release: pipeline v1.3.0 
    v1.3.0 — claude-drift-triage component

Adds claude-drift-triage to the catalog. LLM-augmented schema
drift triage: a consumer's drift command emits diffs; the
component sends them to Claude for classification and concrete
next-step suggestions; optionally opens a GitLab issue with the
triage.

No breaking changes; existing components unchanged. CI image
unchanged (curl + jq + bash already present).

Validated via glab api ci/lint against a synthetic consumer
(see commit 0d04dfa).