fix(ci): wake release-plz back up with git_only, and make idling loud - #46
Merged
Conversation
release-plz has opened no release PR since v0.3.0. Every run was green:
`release-pr` returned {"prs":[]} and `release` printed "nothing to release",
with no error and no annotation. v0.3.1 had to be versioned and tagged by hand.
The cause is 210143b, which added `publish = false` to Cargo.toml to stop
release-plz comparing against the unrelated `dit` crate squatting the name on
crates.io. That works, but release-plz's FAQ is explicit that it "publishes all
packages, except: packages with `publish = false` in the Cargo.toml" — so the
package stopped being processed at all.
`git_only = true` is the field that actually expresses the intent 210143b had:
it determines the latest version from git tags instead of the registry, and
skips `cargo publish` on its own. `publish = false` in release-plz.toml never
could — the docs note it "will still use the cargo registry to check what's the
latest release", which is exactly the phantom-PR bug PR #39 was chasing.
Crucially, git_only also re-admits a private package: release-plz PR #2603
("consider private `git_only` packages", merged 2026-01-23, in the 0.3.160 we
run) makes a `publish = false` manifest eligible again. So Cargo.toml keeps its
accidental-publish guard and release-plz starts proposing versions again.
Both comments that asserted the old, wrong model are rewritten in place.
Finally, a silent green no-op is what let this run for a month unnoticed, so
release-plz.yml now warns when it proposes nothing while feat/fix/breaking
commits sit since the last tag. Checked against real history: 3 hits across the
v0.3.0..v0.3.1 window, 0 on a chore/docs-only window, and it catches `type!:`
breaking changes of any type.
filipeforattini
added a commit
that referenced
this pull request
Jul 31, 2026
#47) Enabling git_only in #46 got release-plz reading versions from git tags — the log now says `Latest release of package dit: tag v0.3.1` instead of silently skipping the package — but it then failed at `failed to determine next versions: run cargo package`. git_only compares the working tree against the tagged release via `cargo package`, which verifies by *building*. alsa-sys's build script panics without libasound, and this job is the only one that never installed it: before git_only it never compiled anything. ci.yml and release.yml both already do. Upstream has an open issue for the underlying brittleness (release-plz #2789, "fall back to source dir comparison when cargo package fails"); installing the dep sidesteps it rather than waiting on it.
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
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.
release-plz has opened no release PR since v0.3.0 — across a month of green runs.
release-prreturned{"prs":[]},releaseprintednothing to release, no error, no annotation. v0.3.1 had to be versioned and tagged by hand (#45).Cause
210143b added
publish = falseto Cargo.toml to stop release-plz comparing versions against the unrelatedditcrate (0.0.1, 2022) squatting the name on crates.io. It does stop that — by making release-plz skip the package entirely. Its FAQ:Fix
git_only = trueinrelease-plz.tomlis the field that expresses what 210143b actually wanted:publish = falsein release-plz.toml never could do this — the docs are explicit that it "will still use the cargo registry to check what's the latest release", which is the phantom-PR bug #39 chased.And
git_onlyre-admits a private package: release-plz #2603 — "When a package is marked withpublish=falsein its manifest, we should still consider it for release if it isgit_only=true" — merged 2026-01-23, well inside the 0.3.160 we run. So Cargo.toml keeps its accidental-publish guard and release-plz starts proposing versions again.Both code comments that asserted the old, wrong model are rewritten in place, since believing them is what caused this.
Making the failure mode visible
The real damage was that idling looks exactly like health.
release-plz.ymlnow warns when release-plz proposes nothing while version-bumping commits sit since the last tag.Checked against real history: 3 hits across the
v0.3.0..v0.3.1window (the silent period), 0 on a chore/docs-only window, and it catchestype!:breaking changes of any type.Verification
Config-only — nothing to run locally. The real proof is the next push to
main: this PR merging should itself make release-plz open achore: release v0.3.2PR. If it stays silent, the new warning will now say so instead of passing green.Open upstream caveat worth watching: release-plz #2693 reports
git_only = truestill attempting to publish in some setups. Cargo.toml'spublish = falseis a hard backstop if that bites — cargo itself would refuse.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.