Auto Cherry-Pick: Fix race condition in workflow trigger#76083
Auto Cherry-Pick: Fix race condition in workflow trigger#76083
Conversation
…sed event The workflow was using a `push` trigger which lacks PR context, forcing an API lookup via `listPullRequestsAssociatedWithCommit`. This API has eventual consistency, so it often returned no results when the workflow ran immediately after a merge. Replace the `push` trigger with `pull_request_target: [closed, labeled]`. The `closed` event fires on merge with the full PR payload, eliminating the need for any API lookups. The PR number, merge commit SHA, and labels are all read directly from `context.payload.pull_request`. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
ellatrix
added
the
[Type] Automated Testing
|
Flaky tests detected in 783f353. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22624224343
|
| const pr = context.payload.pull_request; | ||
| const commit_sha = pr.merge_commit_sha; | ||
| const pr_number = pr.number; | ||
| console.log(`Commit SHA: ${commit_sha}`); |
There was a problem hiding this comment.
Not for today because there are many instances throughout the file, but we should switch to using the GitHub @actions/core package's logging functions (core.warning(), core.error(), core.info()).
core.info() just prints output into the workflow log, but core.warning() an core.error() are surfaced in the Actions Summary UI, which can be helpful to surface information from the run that should be easier to spot. For example, using core.error() could be helpful when a conflict is encountered.
I made a note for myself to open a new ticket.
There was a problem hiding this comment.
Ok sounds good to do it systematically then :)
|
Thanks for double checking. Yes, we'll soon test it for newly merged PRs with the label |
2 participants
Unifies some auto cherry pick workflow logic. We keep having problems when PRs are merged that the PR associated with the commit is not found yet, example: https://github.com/WordPress/gutenberg/actions/runs/22608569676/job/65506086536
Summary
pushtrigger withpull_request_target: [closed, labeled]to fix a race condition where the workflow couldn't find the PR for a merge commitpushevent lacks PR context, forcing an API lookup vialistPullRequestsAssociatedWithCommitwhich has eventual consistency — it often returns no results when the workflow runs immediately after a merge (example)closedevent fires on merge with the full PR payload, so the PR number, merge commit SHA, and labels are read directly fromcontext.payload.pull_request— no API lookups neededTest plan
Backport to WP X.Y Beta/RClabel and verify the cherry-pick workflow runs successfullyBackport to WP X.Y Beta/RClabel to an already-merged PR and verify the cherry-pick workflow runs successfullymerged == truecondition)🤖 Generated with Claude Code