ci: release-create job for tag pipelines

Andrew Dunnrequested to merge
andunn-release-job into main

What this MR ships

Closes the kaniko CI gap surfaced when v1.0.0 was tagged: the release stage was declared in .gitlab-ci.yml but no job populated it, so the tag pipeline succeeded but no GitLab Release page was created.

This MR adds a release-create job in the release stage that fires on tag pipelines ($CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+/) and uses the release-cli image to publish a GitLab Release page automatically. The release description is sourced from the annotated tag's message body (CI_COMMIT_TAG_MESSAGE), so the tag IS the source of truth -- updating release notes means re-tagging.

What changes

  • New release-create job appended to .gitlab-ci.yml. Forty-six lines, all inside the existing release stage. No other jobs touched.
  • needs: includes fips-smoke and container-verify-debug-fips-strict (both optional: true) so the release page is gated on the heaviest verification cells but the dependency graph still parses cleanly if upstream rules filter either job in a future pipeline.
  • Asset links on the release page point at the container registry and the docs site. Minimal but stable. Direct artifact downloads (SBOM and provenance files) are a follow-up once we have a stable extraction path that doesn't depend on the registry UI.

Why the inline job and not a catalog component

The right end state is a pipeline/release catalog component every public-sector consumer can lift. This MR keeps the change small enough to land tonight; the catalog component is filed separately as a follow-up against public-sector/pipeline.

v1.0.0 backfill

v1.0.0 was manually created via glab release create v1.0.0 --notes "$(git tag -l --format='%(contents)' v1.0.0)". v1.0.1 is the first tag that exercises this job end-to-end, which validates the CI change against a live tag pipeline.

Test plan

  • MR pipeline runs the full build matrix as before; new job does not fire on MR events (rule gated on CI_COMMIT_TAG).
  • Merge MR; main pipeline runs without the release job (same rule).
  • Tag v1.0.1 after merge; release-create job fires on the tag pipeline.
  • Verify the GitLab Release page lands at https://gitlab.com/gitlab-com/public-sector/kaniko/-/releases/v1.0.1 with the tag annotation body as its description and both asset links present.

Follow-up

  • File against gitlab-com/public-sector/pipeline: propose a pipeline/release catalog component so every estate consumer picks this up without lifting the inline job.
  • Asset linking for SBOM + provenance file downloads (separate MR once the extraction shape is stable).

🤖 Generated with Claude Code

Merge request reports