ci: declare workflow-level contents: read on 6 workflows

[arpitjain099]

Pins the default GITHUB_TOKEN to contents: read on 6 workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load on each touched file.

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

[greptile-apps]

Greptile Summary

This PR pins the GITHUB_TOKEN to contents: read at the workflow level across six CI/CD workflows that only need repository checkout access, reducing the token's blast radius if any action in these workflows is ever compromised.

• Six workflows hardened: ci-main.yml, ci-pull-request.yml, docker-build-arm.yml, integration-test-library-mode.yml, retriever-unit-tests.yml, and scheduled-nightly.yml each receive a top-level permissions: contents: read block placed correctly after the on: / concurrency: sections.
• No functional breakage: All privileged operations in these workflows (Docker registry pushes in scheduled-nightly.yml, Artifactory publishes, NVIDIA API calls) authenticate via dedicated secrets rather than GITHUB_TOKEN, so restricting the token scope has no runtime impact.
• Reusable workflow compatibility confirmed: The called reusable workflows declare no permissions: of their own and use only artifact upload/download operations (which rely on ACTIONS_RUNTIME_TOKEN, not GITHUB_TOKEN), so they continue to work correctly under the caller's reduced scope.

Confidence Score: 5/5

Safe to merge — the change only adds a least-privilege contents: read scope to six workflows, and every privileged operation in those workflows (Docker pushes, PyPI publishes) uses its own dedicated secret rather than GITHUB_TOKEN.

Each of the six modified workflows was verified against its reusable dependencies and confirmed to need no GITHUB_TOKEN scope beyond repository checkout. No functional paths are broken by the restriction.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/ci-main.yml	Adds workflow-level permissions: contents: read; the two reusable workflows it calls (pre-commit and docker-build-and-test) require no additional GITHUB_TOKEN scopes.
.github/workflows/ci-pull-request.yml	Adds workflow-level permissions: contents: read; all jobs only need repo checkout access from GITHUB_TOKEN.
.github/workflows/docker-build-arm.yml	Adds workflow-level permissions: contents: read; Docker build is local-only (--load, no push).
.github/workflows/integration-test-library-mode.yml	Adds workflow-level permissions: contents: read; workflow only checks out code and runs integration tests using injected NVIDIA API key secrets, not GITHUB_TOKEN.
.github/workflows/retriever-unit-tests.yml	Adds workflow-level permissions: contents: read; workflow only checks out code and runs unit tests — no GITHUB_TOKEN write operations at all.
.github/workflows/scheduled-nightly.yml	Adds workflow-level permissions: contents: read; Docker pushes use DOCKER_PASSWORD secret and PyPI publishes use Artifactory credentials — neither relies on GITHUB_TOKEN.

_{Reviews (2): Last reviewed commit: "Merge branch 'main' into chore/declare-w..." | Re-trigger Greptile}