CLP-1174 split unified dogfooding in two steps

[BartLucien]

Part of CLP-906

---

Summary by Gitar

• Workflow split:
  • Split unified-dogfooding into build and run_iris jobs
  • run_iris runs only when build succeeds via needs
• Concurrency:
  • Added workflow-level concurrency group with cancel-in-progress: true
  • run_iris uses a single-queue iris concurrency group
• Permissions:
  • build job now requests contents: write

_{This will update automatically on new commits.}

[hashicorp-vault-sonar-prod]

CLP-1174

[gitar-bot]

💡 Security: contents permission raised from read to write in both jobs

The old single job ran the same build-maven shadow-scan step and the same run-iris step with contents: read, so neither step needs write access to the repository. The split gives both build and run_iris contents: write, which lets their GITHUB_TOKEN push commits and tags. run_iris has no checkout and only calls an external action, so this widens what a compromised or misbehaving third-party action could do. Keep contents: read in both jobs unless a new requirement is documented.

Restore least-privilege read access (apply to both jobs):

permissions:
  id-token: write
  contents: read

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 1 closed / 2 findings

🔴 High risk · Granting build and IRIS jobs contents: write could let a compromised or misconfigured action alter repository files.

Splits the unified-dogfooding workflow into build and run_iris jobs, with run_iris gated on build success, plus a workflow-level concurrency group and an iris queue for IRIS runs. Consider reverting contents permission from write to read in both jobs, since neither step needs to push commits or tags and the extra write access widens what a compromised third-party action could do.

💡 Security: contents permission raised from read to write in both jobs

📄 .github/workflows/unified-dogfooding.yml:15-17 📄 .github/workflows/unified-dogfooding.yml:44-46

The old single job ran the same build-maven shadow-scan step and the same run-iris step with contents: read, so neither step needs write access to the repository. The split gives both build and run_iris contents: write, which lets their GITHUB_TOKEN push commits and tags. run_iris has no checkout and only calls an external action, so this widens what a compromised or misbehaving third-party action could do. Keep contents: read in both jobs unless a new requirement is documented.

Restore least-privilege read access (apply to both jobs)

permissions:
  id-token: write
  contents: read

✅ 1 closed

Closed: Bug: Workflow-level cancel-in-progress can still cancel a running IRIS job

📄 .github/workflows/unified-dogfooding.yml:7-9 📄 .github/workflows/unified-dogfooding.yml:38-41
run_iris sets cancel-in-progress: false on its iris group, so a running IRIS analysis should not be interrupted. The PR also adds a workflow-level concurrency group (${{ github.workflow }}-${{ github.ref }}) with cancel-in-progress: true. That group cancels the whole older workflow run, run_iris included, whenever a new run starts on the same ref, for example a workflow_dispatch while the 04:00 scheduled run is still in its IRIS phase. Before this PR the workflow had no concurrency settings, so a manual dispatch could not abort an in-flight IRIS run. To fix this, drop cancel-in-progress: true at the workflow level or set it to false, or move the cancelling concurrency onto the build job only.

🤖 Prompt for agents

Code Review: Splits the `unified-dogfooding` workflow into `build` and `run_iris` jobs, with `run_iris` gated on `build` success, plus a workflow-level concurrency group and an `iris` queue for IRIS runs. Consider reverting `contents` permission from `write` to `read` in both jobs, since neither step needs to push commits or tags and the extra write access widens what a compromised third-party action could do.

1. 💡 Security: contents permission raised from read to write in both jobs
   Files: .github/workflows/unified-dogfooding.yml:15-17, .github/workflows/unified-dogfooding.yml:44-46

   The old single job ran the same `build-maven` shadow-scan step and the same `run-iris` step with `contents: read`, so neither step needs write access to the repository. The split gives both `build` and `run_iris` `contents: write`, which lets their GITHUB_TOKEN push commits and tags. `run_iris` has no checkout and only calls an external action, so this widens what a compromised or misbehaving third-party action could do. Keep `contents: read` in both jobs unless a new requirement is documented.

   Fix (Restore least-privilege read access (apply to both jobs)):
   permissions:
     id-token: write
     contents: read

Verification

Functional validation No results

Rules No rules evaluated

Auto-approval Not enabled

Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[aurelien-coet-sonarsource]

LGTM 👍