ci: adopt pipeline/release@v3.3.2 + bump other catalog pins

Andrew Dunnrequested to merge
andunn-adopt-release-component into main

What this MR ships

Closes the architectural loop on the v1.0.1 release-page backtick bug. Replaces the inline release-create job (introduced in MR !10 (merged)) with the now-fixed pipeline/release@v3.3.2 catalog component. Bumps every other catalog pin to v3.3.2 in the same change.

What changes

.gitlab-ci.yml:

  • Adopted pipeline/release@v3.3.2 in the include: block (right after the verify components). Inputs: package_name: "" (kaniko doesn't ship to the generic package registry), container_image: $CI_REGISTRY_IMAGE.
  • Deleted the 45-line inline release-create: job. The brief comment that remains points to the include block.
  • Bumped every catalog pin from @v3.2.0 to @v3.3.2: container-scan-summary, compliance, vale, container (×7 variants), container-sbom (×7), container-attest (×7), verify (×7). 31 pin changes in one uniform bump.

CHANGELOG.md: Unreleased ### Changed entry covering the inline-to-catalog swap + the uniform pin bump.

Why the catalog component is the right shape

The inline job had two bugs that v3.3.2 fixes:

  1. Shell-eval-on-backticks. The GitLab release: keyword routed ${CI_COMMIT_TAG_MESSAGE} through shell eval, treating backticks as command substitution. Every code span in tag annotations was silently stripped from the rendered release page. Validated end-to-end on kaniko v1.0.1 (manually re-updated post-tag) and proven on the catalog's own v3.3.2 self-dogfood (34-backtick parity from source tag annotation to rendered release page).

  2. Re-run idempotency. The keyword refused to update existing releases with --no-update; force-pushed tag re-runs failed with "release already exists". The catalog uses glab release create --notes-file which idempotently updates.

Why v3.3.2 and not v3.3.1: v3.3.1's tag pipeline blocked on an unrelated GOVULNCHECK_VERSION pin bug (pipeline!58 (merged)). v3.3.2 carries both the backtick fix (originally MR !57) and the pin fix together.

Test plan

  • MR pipeline lints + runs the full build matrix at the new v3.3.2 pins
  • On merge, main pipeline rebuilds + signs all seven variants at the new component versions (no release-stage activity since main isn't a tag)
  • Tag v1.0.2 after merge: tag pipeline fires the catalog's release component end-to-end. Backtick count in the v1.0.2 release page description must equal the source tag annotation's backtick count
  • Re-tag scenario: if v1.0.2 needs a tag-body fix, force-push v1.0.2 with new annotation. Re-run tag pipeline updates the existing release page (no "already exists" failure)

🤖 Generated with Claude Code

Merge request reports