Signature
Three signals appear together. One alone is not conclusive, but all three at once mean the pipeline is wedged.
Confirm it in one pass:
origin is the whole diagnosis.
Cause
Release Please decides what work remains from two places: the version in.release-please-manifest.json and the label on the release pull request. Merging the release pull request updates the manifest in the same commit, but creating the tag and the GitHub release is a separate step that runs afterwards.
When that second step does not complete, the two disagree permanently. The manifest claims a version that was never tagged, and the pull request keeps its autorelease: pending label. Every later run finds the same merged pull request, decides the release is still outstanding, warns and stops. It never opens the next release pull request, so the repository silently stops releasing.
Because docker-publish.yml runs only when release_created is true, no images are built either. Documentation that tells operators to pull a published tag then points at something that does not exist.
The cause seen in this repository
Both0.4.0 and 0.5.0 wedged for the same reason, and it is a configuration mismatch rather than a transient failure. The Release run logs it just before it gives up:
release-please-config.json sets release-type: node, so the component is read from the root package.json name, which is asobeast. Setting or removing package-name in the config does not change that, because the node strategy falls back to reading package.json directly.
With separate-pull-requests disabled, the release pull request is a grouped one on the branch release-please--branches--main, which carries no component. When the merged pull request is read back, it is evaluated as a standalone release, and that path requires the branch component to equal the configured component. An empty component never equals asobeast, so no release is ever built.
Until that configuration is corrected, every release needs the recovery below. The guardrail described under Prevention makes the failure loud, so it is caught on the run that causes it rather than weeks later.
Recovery
Run these in order, from an up to datemain. Steps 1 and 2 are public and effectively irreversible, so verify the commit before pushing.
1
Tag the commit the release pull request merged
Take the merge commit of the release pull request, not the current tip of The ancestor check must print
main. Everything after it belongs to the next release.ancestor before you tag.2
Create the release from the changelog section
Release Please already wrote the notes. Extract them rather than retyping them, so the release and the changelog cannot disagree.
--verify-tag fails rather than inventing a tag if the push in step 1 did not land.3
Relabel the release pull request
This is what tells Release Please the release is finished. Without it the tool keeps reprocessing the same pull request and never proposes the next version.
4
Publish the images
docker-publish.yml accepts a manual dispatch with a tag input.linux/amd64 and linux/arm64.5
Confirm the tool recovers
Merge any pull request into A fresh release pull request proves the tool moved on. It does not prove the next release will tag itself: while the component mismatch above stands, that release wedges too and the guardrail fails the run again.
main, then check that a fresh release pull request opens for the next version and that the warning is gone.A recovery dispatch builds the tag you pass rather than the tip of
main, so the images it produces carry the same tags a normal release would. Verify the version tag resolves before you tell anyone to pull it.The release pull request needs its workflows approved
A release pull request is opened bygithub-actions[bot], and its workflow runs land in the action_required state rather than starting on their own. main requires the checks, e2e, web-e2e and compose-smoke contexts, so until those runs are approved the release pull request reports no checks at all and cannot be merged.
This looks like a wedged pipeline but is not one. Approve the waiting runs, let them finish, then merge:
Prevention
release.yml runs a verify-release-state job on every push that does not create a release. It asserts that the version in .release-please-manifest.json exists as a tag on origin and fails the workflow with an annotation when it does not. The wedged state that once reported success now stops the pipeline the first time it appears.
ci.yml reports the same invariant as a warning on every pull request, so an author sees an unhealthy release pipeline before merging rather than after.
Next steps
Run a published release
Which tags are published for each release, and how to pin one.
Troubleshooting
Symptoms a running instance produces, with causes and fixes.