fix(release): sync Cargo.lock on release so --locked builds pass#43
Merged
Conversation
release-please bumps the workspace version in Cargo.toml via the
x-release-please-version annotation but leaves Cargo.lock untouched, so the
csp/csp-cli lock entries stayed at the old version. The v0.1.0 release build
failed on every target with `cargo build --release --locked` ('cannot update
the lock file because --locked was passed').
- regenerate Cargo.lock to match the 0.1.0 workspace version (unbreaks main)
- add a 'Sync Cargo.lock' step to release-please.yml that runs
'cargo update -p csp -p csp-cli' on the release PR branch and commits the
lockfile, mirroring the existing bun.lock sync step
📝 WalkthroughWalkthroughA new "Sync Cargo.lock" step is added to the ChangesCargo.lock Sync in Release Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release-please.yml (1)
80-80: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winHarden shell interpolation for PR branch ref before
git push.Line 80 expands
headBranchNamedirectly in the shell command. Move it to an env var and quote the refspec to avoid template-to-shell injection risk and satisfy the zizmor finding.Suggested patch
- name: Sync Cargo.lock if: ${{ steps.release.outputs.pr }} + env: + RELEASE_PR_HEAD_BRANCH: ${{ fromJson(steps.release.outputs.pr).headBranchName }} run: | cargo update -p csp -p csp-cli if git diff --quiet Cargo.lock; then echo "Cargo.lock already in sync" else git config user.name "github-actions[bot]" git config user.email "github-actions[bot]`@users.noreply.github.com`" git add Cargo.lock git commit -m "chore: sync Cargo.lock" - git push origin HEAD:${{ fromJson(steps.release.outputs.pr).headBranchName }} + git push origin "HEAD:${RELEASE_PR_HEAD_BRANCH}" fi🤖 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-please.yml at line 80, The git push command on line 80 directly interpolates the headBranchName value from the release step output in the shell command, creating a potential template-to-shell injection vulnerability. To fix this, extract the headBranchName value from steps.release.outputs.pr and assign it to an environment variable in a previous step, then reference that environment variable in the git push command with proper quoting around the refspec argument to safely pass the branch reference.Source: Linters/SAST tools
🤖 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-please.yml:
- Line 80: The git push command on line 80 directly interpolates the
headBranchName value from the release step output in the shell command, creating
a potential template-to-shell injection vulnerability. To fix this, extract the
headBranchName value from steps.release.outputs.pr and assign it to an
environment variable in a previous step, then reference that environment
variable in the git push command with proper quoting around the refspec argument
to safely pass the branch reference.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 69ed9bb4-0c1d-4fee-904b-cdae2f1ecea4
⛔ Files ignored due to path filters (1)
Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (1)
.github/workflows/release-please.yml
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
No issues found across 2 files
Architecture diagram
sequenceDiagram
participant GitHub as GitHub Actions
participant RP as Release-Please
participant RPBranch as Release PR Branch
participant CargoToml as Cargo.toml
participant CargoLock as Cargo.lock
participant RustBuild as Release Rust Build
participant Publish as Publish Steps (npm/homebrew)
GitHub->>RP: Trigger release-please workflow
RP->>RP: Bump workspace version in Cargo.toml
RP->>CargoToml: Write v0.1.0 (or new version)
RP->>CargoLock: No change (entries stay at old version)
RP->>RPBranch: Push PR with Cargo.toml updated, Cargo.lock stale
Note over GitHub,RustBuild: New Sync Cargo.lock step
GitHub->>GitHub: Check if release PR exists
alt Release PR exists
GitHub->>CargoLock: Run cargo update -p csp -p csp-cli
alt Cargo.lock differs
GitHub->>CargoLock: Commit updated Cargo.lock
GitHub->>RPBranch: Push commit to release PR branch
else Already in sync
GitHub-->>GitHub: No action needed
end
end
Note over GitHub,Publish: Build and publish (existing flow)
GitHub->>RustBuild: Run cargo build --release --locked
RustBuild->>CargoLock: Read lockfile (now in sync)
RustBuild->>CargoToml: Read manifest (version matches)
alt Lock file matches manifest
RustBuild-->>GitHub: Build succeeds
GitHub->>Publish: Trigger publish steps
Publish-->>GitHub: npm + homebrew published
else Lock file mismatch (old flow)
RustBuild-->>GitHub: Build fails with --locked error
GitHub-->>Publish: Skipped
end
This was referenced Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The v0.1.0 release build failed on every target. release-please bumps the workspace version in
Cargo.toml(via thex-release-please-versionannotation) but does not updateCargo.lock, so thecsp/csp-clilock entries stayed at0.0.0whileCargo.tomlmoved to0.1.0.release-rust.ymlbuilds withcargo build --release --locked, which then fails:release-pleasejob succeeded (v0.1.0 tag/release created) butbuild-and-uploadfailed →publish-npm+ homebrew were skipped → nothing published.Fix
Cargo.lockto match the0.1.0workspace version (also unbreaksmain, which was left mismatched).Sync Cargo.lockstep torelease-please.ymlthat runscargo update -p csp -p csp-clion the release PR branch and commits the lockfile — mirrors the existingbun.locksync step, so future release PRs keep the lock in sync automatically.Recovery plan
Merging this
fix:triggers release-please to cut 0.1.1; the new sync step keeps itsCargo.lockin sync, so that release builds + publishes cleanly via OIDC. The emptyv0.1.0tag/release will be cleaned up afterward.Test plan
cargo metadata --lockedpasses locally after the lock regenSummary by cubic
Fixes release builds by keeping
Cargo.lockin sync with workspace versions. Regenerates the lockfile and adds an automated sync socargo build --release --lockedpasses and publish steps run.Cargo.lockto aligncspandcsp-cliwith0.1.0.release-please.ymlthat runscargo update -p csp -p csp-clion the release PR branch and commits the lockfile.Written for commit 7cc7b83. Summary will update on new commits.
Summary by CodeRabbit