ci(release-plz): add fallback triggers for missed push events#203
Merged
Conversation
…k triggers The 'on: push' trigger has been unreliable — GitHub sometimes does not fire push events after rebase/squash merges of PRs. Repeatedly this has left release-plz stuck on stale state until a manual nudge. Add two fallbacks: - pull_request_target with type=closed (gated by merged==true) catches the merge directly without depending on the push event firing. - Hourly schedule cron is a final safety net — even if both push and PR triggers fail, release-plz will run within an hour. Both fallback triggers explicitly checkout 'main' so the workflow always operates on the right ref regardless of what triggered it (security relevant for pull_request_target). Concurrency group is now keyed on a constant 'release-plz-main' so all triggers (push / pull_request_target / schedule / dispatch) share one slot instead of creating per-PR groups.
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
1 participant
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.
Problem
The release-plz workflow uses
on: push: branches: [main]as its only trigger. GitHub Actions sometimes fails to fire push events after rebase/squash merges of PRs — see community discussion #26657.This bit us today: PR #200 was merged at 11:23 UTC, the push event was recorded by GitHub, but NO workflows fired (CI, CodeQL, Release-plz all silent). Manual workflow_dispatch returned HTTP 500. Result: release-plz never produced an updated release PR for the new agent-policies features, and we had to consider releasing manually.
This isn't the first time it's happened.
Fix
Add two fallback triggers:
pull_request_targetwithtype=closed, gated bygithub.event.pull_request.merged == true. This catches the merge directly without depending on the push event firing. Per the GitHub discussion linked above, this is the official workaround for missed push-after-merge events.Hourly
schedulecron ('0 * * * *') as a final safety net. Even if both push and PR triggers fail, release-plz will run within an hour.Both fallback triggers explicitly checkout
main(ref: mainonactions/checkout) so the workflow always operates on the right ref regardless of what triggered it. This is also a security best practice forpull_request_target— it ensures we never run untrusted code from a PR's HEAD.Concurrency group is now keyed on a constant
release-plz-mainso all triggers share one slot instead of creating per-PR groups.Notes
pull_request_targetruns in the context of the target branch with secrets — safe here because the workflow checks outmainand ignores PR content.ifguard prevents the workflow running when a PR is closed without merge.concurrency: { cancel-in-progress: false }so duplicate runs from multiple triggers will queue rather than clobber each other.