Feat: Add grype_enabled input to skip the scan

[ModeSevenIndustrialSolutions]

Summary

Adds grype_enabled (boolean, default: true) to all four lanes, so callers can skip the Grype scan without losing the SBOM — and hardens the release gates so a skipped scan cannot be confused with a failed one.

Why

Nothing in the estate could skip Grype. The job hung off the SBOM job:

grype:
needs: 'sbom'if: ${{ !cancelled() && needs.sbom.result == 'success' }}

So the only escape hatch was sbom_enabled: false, which skips the SBOM and silently takes Grype with it — exactly backwards, since SBOM generation is the part we want on by default. Any project that set sbom_enabled: false to get past a blocking CVE has been quietly shipping without an SBOM ever since.

grype_enabled decouples them. The decoupling is deliberately one-way: disabling the scan keeps the SBOM, but disabling the SBOM also stops the scan, which has nothing to read.

Changes

Lane	Grype shape	Gate applied to
build-test	job	job if:
build-test-release	job	job if:
build-test-release-multiarch	matrixed job	job if:
build-test-multiarch	step inside the matrixed sbom job	step if:

That last row is a structural quirk of this repo worth flagging to reviewers — in build-test-multiarch Grype is not a separate job, so the gate lands on the step.

Also reworded the sbom_enabled description, which previously read "also skips the dependent Grype scan job" and implied a deliberate coupling.

Release gate hardening (added after review)

Both release lanes gated downstream jobs with:

contains(fromJSON('["success", "skipped"]'), needs.grype.result)

That accepts every skip as benign, but skipped is ambiguous. Grype skips both when a toggle disables it and when the sbom job fails — so a failed SBOM would have let python-tests and, more seriously, attach-artefacts proceed with no scan performed at all.

This idiom pre-dates this PR. It was latent because a skipped Grype previously required an SBOM failure; grype_enabled makes that state routine and configuration-reachable, so leaving it would mean shipping a known hole behind a newly-common path. Now:

&& (needs.grype.result == 'success'|| (needs.grype.result == 'skipped'&& (!inputs.grype_enabled || !inputs.sbom_enabled)))

A skip is accepted only when a toggle explains it. The Grype clause tests both toggles because either legitimately produces the skip. The same treatment is applied to the sbom and python-audit clauses, on both the python-tests and attach-artefacts gates in both release lanes. attach-artefacts matters most: that gate guards what actually gets released.

Credit to Copilot for spotting this on the companion PRs.

Compatibility

default: true — no existing caller changes behaviour. No inputs removed or renamed. The gate change is strictly more conservative: it can only block where it previously allowed, and only when a scan genuinely did not run.

Validation

• yamllint, actionlint over all workflows and examples — clean
• zizmor --persona=auditor — no new findings (the one self-repository help-level note in testing.yaml is pre-existing and estate-wide)
• Full prek run over the changed files — all hooks passed

Follow-up

lfreleng-actions/workflows-template#57 tracks end-to-end coverage of the opt-out paths, which Copilot rightly asked for and which is deliberately not bolted onto this PR — the multiarch step-level gate is flagged there as the highest-priority case, being the structural outlier.

Context

Part of a seven-PR series standardising these toggles across the workflow estate. Companions: lfreleng-actions/workflows-template#56, lfreleng-actions/go-workflows#67, lfreleng-actions/node-workflows#83, lfreleng-actions/java-workflows#45, lfreleng-actions/docker-workflows#68.

[Copilot]

🟡 Changes recommended

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds an independent grype_enabled toggle across all reusable workflow lanes while preserving SBOM generation.

Changes:

• Adds the boolean input with a backward-compatible true default.
• Gates standalone Grype jobs and the multi-arch Grype step.
• Documents the toggle in caller examples.

File summaries

File	Description
.github/workflows/build-test.yaml	Adds and applies the Grype toggle.
.github/workflows/build-test-release.yaml	Adds release-lane Grype gating.
.github/workflows/build-test-multiarch.yaml	Gates the embedded Grype step.
.github/workflows/build-test-release-multiarch.yaml	Gates the matrixed Grype job.
examples/build-test/github.yaml	Documents the new inputs.
examples/build-test-multiarch/github.yaml	Documents multi-arch usage.

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 2
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[Copilot]

🟢 Approval recommended

Review details

• Files reviewed: 6/6 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[zxiiro]

🤖 Auto-approved by agent: reviewed workflow/code change for security and CI/CD impact, found low risk. Adds additive grype_enabled input defaulting to true across single- and multi-arch workflows. Defaults preserve current scans; no permission/secret/pin changes.