-
-
Notifications
You must be signed in to change notification settings - Fork 728
ci: use classic tokens for crate publishing #7801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
WalkthroughThe publish CI workflow was restructured: the PR branch is explicitly checked out at a specific commit using GITHUB_TOKEN, the Rust toolchain is installed via moonrepo/setup-rust with Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/publish-crates.yml
(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Validate PR title
- GitHub Check: triage
🔇 Additional comments (1)
.github/workflows/publish-crates.yml (1)
11-19
: Verify environment variable scoping and checkout action version.A couple of questions to confirm the workflow behaves as intended:
- The
GITHUB_TOKEN
environment variable on line 18 is nested under theInstall toolchain
step, but the checkout step (lines 11–12) runs first. Does the env var need to be hoisted to apply to the checkout step, or is the current placement correct?- The checkout action is pinned to v4.3.0 (a downgrade from v5 mentioned in the summary). Is this intentional, or should it be updated to the latest v5?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/publish-crates.yml
(1 hunks)
🔇 Additional comments (1)
.github/workflows/publish-crates.yml (1)
10-18
: Workflow structure looks sound.The explicit checkout, Rust toolchain setup via moonrepo, and cargo publish command are all well-structured. The GITHUB_TOKEN placement at job level is appropriate for the checkout step, and using CRATES_IO_TOKEN for cargo publish is correct for classic token-based authentication.
Once the permissions block is addressed, this should be good to go.
permissions: | ||
id-token: write # Required for OIDC token exchange | ||
steps: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Declare minimal required permissions explicitly.
The permissions block is empty, which defaults to the repository's default permissions—potentially overly permissive. Instead, explicitly declare minimal required permissions.
The checkout action requires contents: read
; the cargo publish step doesn't need additional permissions beyond that.
permissions:
+ contents: read
steps:
This addresses the earlier feedback about removing id-token: write
(no longer needed for classic token publishing) whilst following the principle of least privilege.
🧰 Tools
🪛 actionlint (1.7.8)
8-8: string should not be empty
(syntax-check)
8-8: "" is invalid for permission for all the scopes. available values are "read-all" and "write-all"
(permissions)
🤖 Prompt for AI Agents
.github/workflows/publish-crates.yml around lines 8 to 9: the permissions block
is empty which falls back to repo defaults; replace it with an explicit minimal
permissions declaration (remove any id-token: write) and set at least contents:
read for the checkout action so the workflow runs with least privilege.
Summary
When using trusted publishing, it means new crates must be published manually, which is still a DX drawback for us, where we add new crates quite often.
This PR switches the workflow to use the regular publishing system.
Test Plan
N/A
Docs
N/A