chore: declare contents: read on code_quality workflow

[arpitjain099]

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 automation workflow permissions to explicitly grant read access to repository contents, ensuring code-quality processes can access necessary files.

[copy-pr-bot]

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]

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: 12a53f35-e392-4b8e-92cc-59aac18299b1

📥 Commits

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

📒 Files selected for processing (1)

• .github/workflows/code_quality.yml

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/code_quality.yml

---

📝 Walkthrough

Walkthrough

Adds a workflow-level permissions block to .github/workflows/code_quality.yml granting contents: read to the Actions run token. No other workflow jobs, triggers, or steps were changed.

Changes

Workflow Permissions Configuration

Layer / File(s)	Summary
Workflow-level permissions block .github/workflows/code_quality.yml	Adds a top-level permissions configuration that grants contents: read to the workflow run token.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

---

Important

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

❌ Failed checks (1 error)

Check name	Status	Explanation	Resolution
Security Anti-Patterns	❌ Error	PR adds hardcoded trust_remote_code=True in merge_lora.py and test utilities, violating rule #3 requiring caller-configurable params defaulting to False.	Remove hardcoded trust_remote_code=True; restore caller-configurable parameters defaulting to False as in original code.

✅ Passed checks (5 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 a contents: read permission declaration to 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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[kevalmorabia97]

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

[arpitjain099]

@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.

[arpitjain099]

The effective default depends on the repo-wide Actions setting under Settings > Actions > General > Workflow permissions. If that's set to "Read and write permissions" (which is GitHub's default for new repos), then GITHUB_TOKEN actually defaults to write across most scopes, not read. Setting contents: read explicitly here pins the workflow's intent so it stays correct even if the repo-wide default changes, and matches what twelve other workflows in this repo already do (gpu-tests.yml, unit.yml, etc.).