Tags give the ability to mark specific points in history as being important
-
2.5.1
Release: pipeline 2.5.1b3046463 · ·renovate preset: lift UBI X.Y allowedVersions estate-wide
-
2.5.0
Release: pipeline 2.5.06ee131f3 · ·2.5.0 - extra_sbom_jobs array on release-create release-create now accepts an `extra_sbom_jobs:` type-array input backing a new `upload-extra-sbom-assets` job, so consumers shipping N SBOMs per release can link all of them to the GitLab Release page. Backward compat: omitting `extra_sbom_jobs` keeps the prior single- SBOM behavior; the new job runs tag-only as a cheap no-op when the input is defaulted. GitLab CI components only support whole-value array substitution, so the multi-SBOM path lives in a second job rather than expanding the existing upload-release-assets needs: block.
-
2.3.3
Release: pipeline 2.3.3585aa3d5 · ·2.3.3 fix(container-sbom): sbom_filename input. Multi-image consumers that collocate SBOMs under one package_name can now give each job a distinct output filename so they don't overwrite each other. Default behaviour unchanged.
-
2.4.0
Release: pipeline 2.4.021750b33 · ·2.4.0 — Renovate preset, validator gate, daily cadence This release introduces the estate-wide Renovate preset as a public catalog surface, alongside the per-tag rebuild of ci-* images and the component versions that have always shipped on tag. What consumers gain ------------------- A central preset published from this repo. Every consumer renovate.json can shrink to a single line: { "extends": ["gitlab>dunn.dev/pipeline:renovate-config"] } The preset carries: platformAutomerge: true (GitLab merges minor+patch on green CI without waiting for the next Renovate run), prHourlyLimit: 0 (no per-hour cap; daily run drains the queue), assignees set to the maintainer accounts (so manual-review MRs land in the inbox), the minor+patch automerge + major manual-review packageRules, and the shared Containerfile ARG customManager used by every Pattern A repackaging consumer (caddy-estate, pipeline's own ci-* images, future auth upstream-software containers). No `schedule` field in the preset. Cadence is owned by the runner's CI cron schedule alone, with RENOVATE_FORCE overriding any stale per-repo schedule at scan time. Operational changes in this repo -------------------------------- - New `validate-renovate` job runs `renovate-config-validator --strict` on every MR touching renovate.json or renovate-config.json. A malformed preset cannot reach consumers. - Renovate runner job drops $CI_PIPELINE_SOURCE == "web". Entry points are `schedule` (daily cron) and `api` only. - Pipeline's own renovate.json now extends the preset and keeps only the two catalog-specific managers: UBI date-stamped-tag filter and the templates/*.yml Docker pin regex. - README gains an Architecture section with the end-to-end Mermaid diagram of the single-maintainer estate. Container images ---------------- ci, ci-go, ci-rust, ci-runtime-go, ci-runtime-node all published at :2.4.0 alongside this tag, matching every consumer's @2.4.0 pin under the v2.0.0 triple-coupling contract. Migration --------- No breaking changes for existing consumers. Per-repo renovate.json files continue to work; migration to the central preset is hygiene and can be done one repo at a time. The fan-out lands as a sequence of small per-repo MRs starting with dunn.dev/reference. -
2.3.2
Release: pipeline 2.3.2b570d1f3 · ·2.3.2 chore: UBI runtime bases on clean X.Y tags. - ci-runtime-go: ubi9/ubi-micro:9.8 (was 9.7-1778461406) - ci-runtime-node: ubi9/nodejs-22-minimal:9.8 (was :1) Plus renovate.json package rule constraining UBI image tag matching to /^[0-9]+\.[0-9]+$/, preventing drift back to date-stamped tags. Same UBI under the hood; cleaner pin, less PR churn for consumers.
-
2.3.1
Release: pipeline 2.3.107da19fd · ·2.3.1 fix(node-publish): tarball path. The 2.3.0 node-publish template wrote tarballs to ../dist (above CI_PROJECT_DIR), breaking the artifacts:paths scope. Downstream node-sbom + slsa-attest failed. Switched to \${CI_PROJECT_DIR}/dist consistently. -
2.3.0
Release: pipeline 2.3.0279fa18f · ·2.3.0 Major catalog uplift for the dunn.dev estate supply chain: - node-* templates (node-build, node-audit, node-publish, node-sbom) bring npm packages to parity with Go binaries: signed releases via cosign sign-blob of the tarball, CycloneDX SBOM, npm publish to GitLab project registry. - container-sbom template: CycloneDX SBOM for built container images via syft scanning the pushed registry image. - container-image: new publish_at_root mode for estate-shared images (e.g. dunn.dev/caddy-estate) that publish at the registry repo root instead of an image_tag sub-path. - ci-runtime-node: new UBI 9 nodejs-22-minimal runtime base for Node SSR consumers. Pairs with container-image (from_artifacts: true). - ci-rust: Zig 0.15.x URL naming fix (arch order changed upstream).
-
2.2.3
Release: pipeline 2.2.3d77def3f · ·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 · ·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
Release: pipeline 2.2.1d1f57eb1 · ·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
Release: pipeline 2.2.03f6286a3 · ·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
Release: pipeline 2.1.2df3c7285 · ·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
Release: pipeline 2.1.1ad59eaf7 · ·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
Release: pipeline 2.1.098661598 · ·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
Release: pipeline 2.0.36d99f964 · ·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
Release: pipeline 2.0.20abd3e28 · ·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
Release: pipeline 2.0.1f96eadc2 · ·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
Release: pipeline 2.0.08a2f4760 · ·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
Release: pipeline v1.8.000412a7f · ·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
Release: pipeline v1.7.03698a767 · ·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.