Skip to content

fix(ci): gate crates-io-publish on releases_created#388

Merged
githubrobbi merged 1 commit into
mainfrom
fix/gate-publish-on-releases-created
Jun 10, 2026
Merged

fix(ci): gate crates-io-publish on releases_created#388
githubrobbi merged 1 commit into
mainfrom
fix/gate-publish-on-releases-created

Conversation

@githubrobbi

Copy link
Copy Markdown
Collaborator

The crates-io-publish job depends on release-plz-release, which runs on
EVERY push to main and no-ops internally when HEAD is not a release-PR
merge. With ENABLE_CRATES_IO_PUBLISH now set (R9 activation), the
publish job would therefore fire on every push: paging the environment
reviewer for approval, then failing on 'crate version already exists'
when republishing the live version.

Root-cause fix: expose releases_created as a job output of
release-plz-release and require it alongside the repo-variable gate, so
the publish job only runs when release-plz actually cut a release (a
freshly bumped version exists to publish). actionlint clean.

The crates-io-publish job depends on release-plz-release, which runs on
EVERY push to main and no-ops internally when HEAD is not a release-PR
merge. With ENABLE_CRATES_IO_PUBLISH now set (R9 activation), the
publish job would therefore fire on every push: paging the environment
reviewer for approval, then failing on 'crate version already exists'
when republishing the live version.

Root-cause fix: expose releases_created as a job output of
release-plz-release and require it alongside the repo-variable gate, so
the publish job only runs when release-plz actually cut a release (a
freshly bumped version exists to publish). actionlint clean.
@githubrobbi githubrobbi enabled auto-merge (squash) June 10, 2026 22:52
@githubrobbi githubrobbi merged commit ec06cd3 into main Jun 10, 2026
19 checks passed
@githubrobbi githubrobbi deleted the fix/gate-publish-on-releases-created branch June 10, 2026 23:06
githubrobbi added a commit that referenced this pull request Jun 11, 2026
…rigger (#389)

Root cause of 'PR merged, nothing happened': the release-plz push
trigger was commented out (workflow_dispatch-only) after the 2026-06-09
re-activation failed 4 consecutive runs, so the #387/#388 merges to
main triggered no release-pr run at all.

Those failures were structural, not transient: in git_only mode
release-plz hardcodes 'cargo package --allow-dirty --workspace' inside
the latest-tag worktree (verified with RUST_LOG=debug on 0.3.157),
packaging ALL members regardless of release=false config. Never-publish
crates with versioned internal deps (uffs-broker ->
uffs-broker-protocol) can never resolve from the crates.io index;
dropping the version instead fails with 'all dependencies must have a
version requirement' -- both directions reproduced locally. Git-only
mode can never work on this workspace, and the old 're-enable after the
internal crates are published' condition was unsatisfiable (they are
never-publish by design).

Fix: git_only = false (registry baseline) -- the flip release-plz.toml's
own R4 comment block planned for post-R8. With uffs-time + uffs-text
v0.5.120 live on crates.io (R8 bootstrap), release-plz downloads the
published .crate files as baseline and never invokes the worktree
packaging step. Verified locally: 'release-plz update' downloads
uffs-text 0.5.120, exits 0, and proposes bumps only when the published
crates' files change.

Also: re-enabled push: branches: [main]; rewrote the two stale deferral
notices in the workflow header as historical records with the
resolution trail; added the matching deviation row + R4 dashboard
correction in release-automation-plan.md. actionlint clean.
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