Skip to content

chore: declare contents: read on code_quality workflow#1480

Open
arpitjain099 wants to merge 1 commit into
NVIDIA:mainfrom
arpitjain099:chore/ci-permissions
Open

chore: declare contents: read on code_quality workflow#1480
arpitjain099 wants to merge 1 commit into
NVIDIA:mainfrom
arpitjain099:chore/ci-permissions

Conversation

@arpitjain099
Copy link
Copy Markdown

@arpitjain099 arpitjain099 commented May 13, 2026

code_quality.yml runs lint and code-quality checks. Twelve other workflows already declare permissions; this brings the remaining quality-check workflow in line.

Summary by CodeRabbit

  • Chores
    • Updated workflow permissions configuration to grant explicit read access for code quality automation.

Review Change Stack

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
@arpitjain099 arpitjain099 requested a review from a team as a code owner May 13, 2026 18:27
@copy-pr-bot
Copy link
Copy Markdown

copy-pr-bot Bot commented May 13, 2026

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 13, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 3fbaa11b-0829-4c92-9032-21cb03d4eede

📥 Commits

Reviewing files that changed from the base of the PR and between 62401e1 and c5e0925.

📒 Files selected for processing (1)
  • .github/workflows/code_quality.yml

📝 Walkthrough

Walkthrough

The pull request adds explicit top-level permissions configuration to the code_quality GitHub Actions workflow, granting contents: read access. This is a security hardening measure that restricts the workflow's default permissions without changing any job steps or scheduling logic.

Changes

Workflow Permissions Hardening

Layer / File(s) Summary
Workflow-level permissions block
.github/workflows/code_quality.yml
Top-level permissions block explicitly grants contents: read to the workflow run, enforcing least-privilege access without modifying job steps or triggers.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 6
✅ Passed checks (6 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately describes the main change: adding an explicit permissions declaration for contents: read in the code_quality workflow.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.
Security Anti-Patterns ✅ Passed PR only modifies .github/workflows/code_quality.yml (YAML), not Python code. The check reviews Python code changes against security practices, making it not applicable here.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands and usage tips.

group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
cancel-in-progress: true

permissions:
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is already the default so why do we need to explicitly set it here?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kevalmorabia97 you're right that the effective scope may already be contents: read on this repo today if the default token scope is set to the restrictive value. The reasons to declare it explicitly anyway:

  1. It documents the actual scope this workflow needs, so a reviewer does not have to check repo-level token settings to know.
  2. It survives repo-default changes. If the default is ever flipped back to permissive (the legacy default which grants contents: write across the board), every workflow that did not explicitly cap stays permissive too.
  3. It matches the in-repo convention: 12 of the 13 sibling workflows in .github/workflows/ already declare permissions: explicitly (bandit.yml, build-docs.yml, ci.yml, etc.); this PR brings the lone remaining one in line.

Defense-in-depth precedent: the tj-actions/changed-files supply-chain attack (CVE-2025-30066, March 2025) showed how an over-scoped GITHUB_TOKEN exfiltrates credentials when a third-party action is compromised. Pinning per workflow caps the blast radius regardless of what the repo default is at any given moment.

Happy to close if you'd prefer to rely on the default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants