ci: set least-privilege workflow permissions

[robnester-rh]

What

Add an explicit least-privilege permissions: block (contents: read) to
this workflow.

Why

Follow-up to EC-2145 (conforma org default workflow permissions set to
read). This workflow had no permissions: block and relied on the implicit
default token. contents: read is the only scope it needs (actions/checkout);
uploads and test steps require no GITHUB_TOKEN scopes. Scoping it explicitly
follows least-privilege and addresses the review feedback that read-all is
broader than necessary.

Co-Authored-By: Claude noreply@anthropic.com
Ref: EC-2171

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 3c52ef6e-b165-4b2b-a062-6665e3e26987

📥 Commits

Reviewing files that changed from the base of the PR and between 4a03b40 and 24706c3.

📒 Files selected for processing (1)

• .github/workflows/build.yaml

Included review availability: Your plan provides up to 12 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The build workflow now explicitly grants read-only access to repository contents.

Changes

Workflow Permissions

Layer / File(s)	Summary
Build workflow permission declaration .github/workflows/build.yaml	The workflow adds a workflow-level contents: read permission.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Merge Risk: ⚪ Minimal · up to 24706

The workflow now explicitly limits its token to contents read, matching its checkout-only use; no actionable merge-blocking risk remains after normal checks and review.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: applying least-privilege permissions to the CI workflow.
Description check	✅ Passed	The description directly explains the addition of an explicit contents: read permission and its purpose.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

Full details: Docstring Coverage

Explanation

No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-for-conforma]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-for-conforma]

PR Summary by Qodo

Set least-privilege permissions for the build workflow

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Grants the build workflow read-only repository content access.
• Removes reliance on organization-level default token permissions.

High-Level Assessment

The explicit workflow-level contents: read grant is optimal because checkout requires repository read access while the remaining build and artifact steps need no additional token scopes. Relying on organization defaults was dismissed because it leaves the workflow's requirements implicit and vulnerable to future default changes.

Files changed (1) +2 / -0

Other (1) +2 / -0

build.yamlRestrict workflow token access to repository contents +2/-0

Restrict workflow token access to repository contents

• Adds an explicit workflow-level 'permissions' block granting only 'contents: read'. This documents the checkout requirement and prevents broader implicit 'GITHUB_TOKEN' access.

.github/workflows/build.yaml

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 9:35 PM UTC · Completed 9:54 PM UTC

Commit: 87c4a29 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $4.75

[github-actions]

🚀 Preview is available at https://fa9800bf.enterprise-contract.pages.dev

[fullsend-ai-review]

Risk Assessment: moderate (2/5)

Details

Single CI workflow config change (.github/workflows/build.yaml, 2 lines) adding explicit least-privilege permissions block. Elevated signals from CI workflow change (score 4) and protected path (score 3) are offset by minimal change size, no dependency changes, and clean git history. Tier 1 composite 1.75, Tier 2 composite 1.33, weighted 1.59 rounds to 2 (moderate).

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] .github/workflows/build.yaml — This PR modifies a file under the .github/ protected path. The PR description provides clear rationale (follow-up to EC-2145, adding least-privilege permissions) and references internal tracker EC-2171. Human approval is always required for protected-path changes, regardless of context.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 1:42 PM UTC · Completed 1:53 PM UTC

Commit: 87c4a29 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $3.68

[fullsend-ai-retro]

Retro: PR #551 — ci: set least-privilege workflow permissions

This was a human-authored 2-line PR (by robnester-rh, co-authored with Claude) adding permissions: contents: read to .github/workflows/build.yaml. The workflow handled this PR well overall.

What went well

• Concurrency handling: The author iterated via 3 force pushes on the original PR ci: set explicit read-all workflow permissions #550 before closing it and re-opening as PR ci: set least-privilege workflow permissions #551 from a fork. This triggered 5 review dispatches total — 2 were correctly cancelled via cancel-in-progress concurrency groups, preventing wasted compute.
• Protected-path detection: The review agent correctly flagged .github/workflows/build.yaml as a protected path requiring human sign-off, and applied the requires-manual-review label.
• Risk assessment accuracy: Moderate risk (2/5) was appropriate — elevated by CI-workflow and protected-path signals, but offset by minimal change size.
• Review verdict: The agent settled on comment (not request-changes), which was the right call for a straightforward security hardening change with clear rationale in the PR body.
• AGENTS.md injection: The harness correctly detected the repo has no AGENTS.md in its git tree and injected the org-level one.

Observation: review pipeline depth vs. change size

The primary review run (33442008873) cost $4.75 and took ~20 minutes at effort: high using claude-opus-4-6. The agent itself classified the change as "mechanical/trivial" and applied per-sub-agent scope constraints (max 5 tool calls). However, the full pipeline still ran: 4 dimension sub-agents (correctness, security, style-conventions, intent-coherence) + risk assessment + adversarial challenger. Of the 4 dimensions, 2 returned info-level findings and 2 returned nothing actionable. The most valuable outputs — protected-path detection and risk assessment — are fixed checks independent of the dimension sub-agents. See proposal below.

No duplicate issues found

Searched conforma/conforma.github.io, conforma/.fullsend, fullsend-ai/fullsend, and fullsend-ai/agents for related open issues. fullsend-ai/fullsend#6822 ("Filter low-severity findings from review runs") is adjacent but distinct — it addresses post-hoc finding filtering, not pipeline-depth reduction for trivial changes.

Proposals skipped (target repo not allowed)

File manually or update create_issues.allow_targets in config.yaml:

• Reduce review pipeline stages for changes classified as mechanical/trivial (fullsend-ai/agents)