ci: authenticate nightly GHCR polling - #668
Conversation
Signed-off-by: Swarom Muley <smuley@nvidia.com>
|
crookedstorm
left a comment
There was a problem hiding this comment.
I think this covers my PR faster than I could get it up. LGTM
📝 WalkthroughWalkthroughChangesNightly release authentication
Sequence Diagram(s)sequenceDiagram
participant poll-final-release
participant Docker
participant Helm
participant GHCR
poll-final-release->>Docker: Login to ghcr.io for nightly containers
Docker->>GHCR: Poll container manifests
GHCR-->>Docker: Container readiness
poll-final-release->>Helm: Login to ghcr.io for nightly charts
Helm->>GHCR: Poll Helm charts
GHCR-->>Helm: Chart readiness
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release.yaml (1)
804-804: 🔒 Security & Privacy | 🔵 TrivialConfirm GHCR package access is granted to this workflow repository.
If the nightly packages are owned by another repository or use granular permissions,
packages: readplus${{ github.token }}is not sufficient: GitHub limitsGITHUB_TOKENto the workflow repository and requires package-level Actions access. Confirm that access is configured, then run the required fresh nightly frommain; otherwise both login steps can still fail withdenied. (docs.github.com)Also applies to: 862-875, 896-904
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yaml at line 804, Verify that the GHCR packages used by the nightly workflow grant Actions access to this workflow repository, especially when packages are owned elsewhere or use granular permissions. Configure the package-level repository access as needed, then run a fresh nightly from main to confirm both GHCR login steps succeed with packages: read and github.token.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/release.yaml:
- Line 804: Verify that the GHCR packages used by the nightly workflow grant
Actions access to this workflow repository, especially when packages are owned
elsewhere or use granular permissions. Configure the package-level repository
access as needed, then run a fresh nightly from main to confirm both GHCR login
steps succeed with packages: read and github.token.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 0c844024-3b8f-4896-8623-db13e8bcecf8
📒 Files selected for processing (1)
.github/workflows/release.yaml
The nightly release run successfully pushed wheels, containers, and the Helm chart, but final artifact polling never got past the first GHCR container. The poll was anonymous because nightly GHCR artifacts were expected to be public; these packages are currently private, so
docker manifest inspectreceiveddeniedand retried as though the artifact had not arrived.This PR gives only the final polling job
packages: readand authenticates Docker and Helm with the repository's built-inGITHUB_TOKENfor nightly runs. Stable container and Helm polling remains anonymous, and no PAT or new secret is introduced.Human attention needed
actionlint,act workflow_dispatch --list, andgit diff --checkpass locally; the failed nightly poll reproduced the anonymousdeniedresponse after the container build had pushed successfullynemo-platformrepository Actions read access; a fresh nightly is still required to prove that package-side configuration end to endRollout
Merge this change, then start a fresh nightly from
main. Rerunning the existing workflow would reuse its original workflow revision and would not exercise this fix.Summary by CodeRabbit