Skip to content

fix(ci): wake release-plz back up with git_only, and make idling loud - #46

Merged
filipeforattini merged 1 commit into
mainfrom
fix/release-plz-git-only
Jul 31, 2026
Merged

fix(ci): wake release-plz back up with git_only, and make idling loud#46
filipeforattini merged 1 commit into
mainfrom
fix/release-plz-git-only

Conversation

@filipeforattini

@filipeforattini filipeforattini commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

release-plz has opened no release PR since v0.3.0 — across a month of green runs. release-pr returned {"prs":[]}, release printed nothing to release, no error, no annotation. v0.3.1 had to be versioned and tagged by hand (#45).

Cause

210143b added publish = false to Cargo.toml to stop release-plz comparing versions against the unrelated dit crate (0.0.1, 2022) squatting the name on crates.io. It does stop that — by making release-plz skip the package entirely. Its FAQ:

Release-plz publishes all packages, except: packages with publish = false in the Cargo.toml.

Fix

git_only = true in release-plz.toml is the field that expresses what 210143b actually wanted:

Enable git-only mode, which determines package versions from git tags instead of the cargo registry. The package will not be published to any cargo registry (cargo publish is skipped).

publish = false in 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_only re-admits a private package: release-plz #2603"When a package is marked with publish=false in its manifest, we should still consider it for release if it is git_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.yml now 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.1 window (the silent period), 0 on a chore/docs-only window, and it catches type!: 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 a chore: release v0.3.2 PR. 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 = true still attempting to publish in some setups. Cargo.toml's publish = false is a hard backstop if that bites — cargo itself would refuse.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

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
filipeforattini merged commit d856141 into main Jul 31, 2026
2 checks passed
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 was referenced Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant