feat(catalog): dogfood ci-buildah for the catalog's own image builds

Andrew Dunnrequested to merge
feat/v2.4.0-dogfood-ci-buildah into main

Summary

The catalog now builds its own images using its own `ci-buildah` image as the build host. The bootstrap note in `.gitlab-ci.yml` has flagged this as the planned dogfooding step since v2.0.0; v2.4.0 is when it lands.

What changed

  • `.image-build:` base image: `quay.io/buildah/stable:v1.43.0` → `registry.gitlab.com/gitlab-com/public-sector-tools/pipeline/ci-buildah:v2.3.0`. Pinned one release behind (v2.3.0) so the bootstrap chain is non-circular — we don't depend on the artifact we're producing.
  • Drop runtime cosign install (ci-buildah has cosign baked). Saves ~5 sec per image build, removes the GitHub CDN dependency that flaked in earlier RC cycles.
  • Bootstrap note in the CI config updated.

Why this is dogfooding (not full)

The catalog's image-build flow is multi-tag aware (resolves at runtime based on tag vs main, RC vs final, etc.) — that's not the shape of the `build-container-buildah` component, which assumes a single-tag-per- include build. So the dogfood here is: use our own ci-buildah image as the build environment rather than wrap our image-build flow in our own component. Full component dogfooding would require either refactoring image-build to instantiate the component N times (losing tag-resolution logic) or evolving the component (probably the right move for a future release).

Test plan

  • MR pipeline runs the same image-build flow under ci-buildah:v2.3.0 and produces signed, pushed images
  • Sim harness passes (sim-buildah-build, sim-go-binary)
  • On merge, main pipeline produces fresh `:latest` images using the dogfooded build host

Followed by tag v2.4.0 which exercises the full release flow.

Merge request reports