Skip to content

fix(ci): re-run the Release PR half after a tag lands #66

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mogita wants to merge 1 commit into from
Closed

fix(ci): re-run the Release PR half after a tag lands #66

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions .github/workflows/release.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -141,6 +141,28 @@ jobs:
target-branch: ${{ github.ref_name }}
skip-github-pull-request: true

# A push that lands while the release above is running is gated out of `release-pr`,
# and nothing re-runs that half once the tag exists, so those commits would sit
# unreleased until the next unrelated push. Run it again now that the walk has a
# release commit to stop at.
release-pr-followup:

@mogita mogita Sep 15, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Substantial] The workflow-level concurrency group already covers the case this job describes, so on that path it has nothing to do.

release.yml:18-20 sets group: release-${{ github.ref_name }} with cancel-in-progress: false. A push that lands while the release run is in flight joins that same group, so its run goes pending and starts only after this run ends. By then the tag exists and release-please has flipped the merged Release PR from autorelease: pending to autorelease: tagged, so that run's own detect reports pending=false and its release-pr job opens exactly the Release PR this job opens. If several pushes land, GitHub keeps only the newest pending run, and release-please walks history, so the survivor still proposes every missed commit.

Put the other way round: detect cannot report pending=true for a commit merged during a release run, because the run that would report it cannot start until the release run is over.

What is left for this job is narrow and is not what the comment says: a push that produces no workflow run at all (a merge made with GITHUB_TOKEN, or [skip ci]), or a queued run whose detect step errors before it can set an output.

Either drop the job, or keep it and rewrite the comment to name the case it actually covers.

@mogita mogita Sep 15, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, and verified against the docs before acting: a second run in the group is pending, and "any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place". So the run that would report pending=true for a commit merged mid-release cannot start until the release run is over, and by then the label has flipped.

Dropped the job. The premise behind it was wrong, not just the comment: I had assumed those pushes execute and skip, rather than queue.

detect's gate still earns its place for the two cases that do reach it, the release run itself and a run following a release that failed after its Release PR merged, so that stays.

name: Release PR (after tagging)
needs: release
if: needs.release.outputs.release_created == 'true'
runs-on: ubuntu-latest
timeout-minutes: 5
permissions:
contents: write
issues: write
pull-requests: write
steps:
- uses: googleapis/release-please-action@v4
with:
config-file: release-please-config.json
manifest-file: .release-please-manifest.json
target-branch: ${{ github.ref_name }}
skip-github-release: true

# Packagist reads the tag itself; this only tells it to look now instead of on its own
# schedule. Idempotent, so the workflow_dispatch input re-announces an existing tag.
packagist:
Expand Down
Loading