fix(ci): skip cargo package verify in release-plz#405
Merged
Conversation
release-plz's release-pr step runs cargo package --verify in a temp worktree that does not honor the committed Cargo.lock. Re-resolution from scratch lands on gix-object 0.58.0 + conflicting winnow 0.7/1.0, the same combo that the gix 0.82 bump already worked around for our lockfile. The verify compile then fails with E0308. Set publish_no_verify so release-plz passes --no-verify. We already have publish = false / git_only = true, so verifying the package compiles in isolation gives us nothing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
avihut
added a commit
that referenced
this pull request
Apr 25, 2026
Reverts the change from #405. publish_no_verify only affects the cargo publish call; release-plz still runs cargo package --verify in the release-pr diff path, so this option does not gate the failure we were trying to fix. The real failure is that release-pr packages the previous released tag (v1.7.2), whose Cargo.toml pins gix = "0.81" and which has no committed Cargo.lock. Fresh resolution from gix 0.81 lands on the broken winnow / gix-object combo. The fix is to cut a v1.8.0 release so the diff baseline becomes a tag that has gix 0.82 plus a committed lockfile; that PR is sent separately. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
avihut
added a commit
that referenced
this pull request
Apr 25, 2026
Reverts the change from #405. publish_no_verify only affects the cargo publish call; release-plz still runs cargo package --verify in the release-pr diff path, so this option does not gate the failure we were trying to fix. The real failure is that release-pr packages the previous released tag (v1.7.2), whose Cargo.toml pins gix = "0.81" and which has no committed Cargo.lock. Fresh resolution from gix 0.81 lands on the broken winnow / gix-object combo. The fix is to cut a v1.8.0 release so the diff baseline becomes a tag that has gix 0.82 plus a committed lockfile; that PR is sent separately. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged
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.
Summary
release-prjob has been failing on every push since1e9dc5be("commit Cargo.lock and bump gix to 0.82").cargo package --verifyin a temp worktree that doesn't honor our committedCargo.lock. The fresh re-resolution lands ongix-object 0.58.0plus the conflictingwinnow 0.7/winnow 1.0combo our committed lockfile avoids, and the verify compile fails withE0308: mismatched typesingix-object/src/parse.rs.publish_no_verify = trueinrelease-plz.toml. We already havepublish = falseandgit_only = true, so the verify compile is wasted work and the only thing the failure blocks is the release PR itself.Fixes the failures on runs
24902568140,24904539960,24935294546, and24935994208.Test plan
masterand confirm the next Release-plz workflow run goes greenreleaselabel and triggers the man-page regeneration step