feat: expose runner_tag input on compliance/attest/sbom/vale

Andrew Dunnrequested to merge
andunn-runner-tag-exposure into main

Summary

Four catalog templates (`compliance`, `container-attest`, `container-sbom`, `vale`) previously had no `runner_tag` input, so their jobs ran on GitLab's default `saas-linux-small-amd64` (1 vCPU, 4 GB). The `container` and `verify` templates already exposed this input. This MR brings the rest of the catalog in line.

What changes

Each of the four templates gains:

  • A `runner_tag` input with default `saas-linux-large-amd64` (4 vCPU, 16 GB)
  • A `tags: [$[[ inputs.runner_tag ]]]` line on the job

Default choice rationale: large is one tier up from the previous implicit small, sized for what each job actually does (cosign attest, syft SBOM generation, markdown parsing, vale install + scan) without overshooting into 2xlarge waste. Consumers that need 2xlarge (e.g. kaniko bumping all jobs to match its build stage) pass it explicitly.

Backward compatibility

Fully additive. Consumers that don't set `runner_tag` get the new default, which is larger than before. No breaking change to call sites; jobs simply run faster.

Test plan

  • CI green
  • kaniko adopts in a follow-up MR by bumping `@v3.1.0` -> `@v3.2.0` and setting `runner_tag` explicitly on the non-build catalog stanzas

Followups

  • Tag `v3.2.0` after merge.
  • kaniko consumer-side adoption: explicit `runner_tag` on the non-build catalog stanzas + bespoke jobs (`fips-smoke`, `dockerfile-lint`) get explicit `tags:` arrays. Bundled with the OCI dynamic-labels follow-up in `kaniko!8`.

Merge request reports