What happened?
The Direct Backport Push workflow (.github/workflows/direct-backport-push.yml) can miss the merged PR immediately after a merge to main, causing the push-backports job to find zero backport targets and get skipped.
Expected behavior: when a PR merged into main has a backport target label such as release/v1.1.0-incubating, the workflow should reliably resolve the merged PR and push the backport on the first run.
Actual behavior: the first run may fail to resolve the merged PR, but re-running the workflow about a minute later succeeds.
Root cause appears to be GitHub's asynchronous commit-to-PR association refresh after squash merge. The workflow currently calls GET /repos/{owner}/{repo}/commits/{commit_sha}/pulls, but the push event can fire before GitHub's association index is ready.
How to reproduce?
- Merge a PR into
main using squash merge.
- Ensure the merged PR has a backport target label such as
release/v1.1.0-incubating.
- Let the
Direct Backport Push workflow run automatically on the merge commit.
- Observe that the
Resolve merged PR and green targets step may fail to find an associated PR and skip push-backports.
- Re-run the same workflow roughly one minute later.
- Observe that the rerun succeeds because the commit-to-PR association is then available.
Concrete example:
- Merge PR:
#4600
- Failing workflow run: 25233602734 attempt 1
- Merge commit SHA:
11d475a2d7406d012a95dd6909c53a13156ef5f5
Version
1.1.0-incubating (Pre-release/Master)
Commit Hash (Optional)
11d475a2d7406d012a95dd6909c53a13156ef5f5
What browsers are you seeing the problem on?
N/A. This issue affects a GitHub Actions workflow rather than the browser UI.
Relevant log output
No merged pull request is associated with 11d475a2d7406d012a95dd6909c53a13156ef5f5.
Additional context
A robust fix would be:
- First parse the squash-merge commit message and extract the PR number from the trailing
(#NNNN) pattern.
- If that does not match, fall back to
commits/{sha}/pulls with retries and exponential backoff before giving up.
What happened?
The
Direct Backport Pushworkflow (.github/workflows/direct-backport-push.yml) can miss the merged PR immediately after a merge tomain, causing thepush-backportsjob to find zero backport targets and get skipped.Expected behavior: when a PR merged into
mainhas a backport target label such asrelease/v1.1.0-incubating, the workflow should reliably resolve the merged PR and push the backport on the first run.Actual behavior: the first run may fail to resolve the merged PR, but re-running the workflow about a minute later succeeds.
Root cause appears to be GitHub's asynchronous commit-to-PR association refresh after squash merge. The workflow currently calls
GET /repos/{owner}/{repo}/commits/{commit_sha}/pulls, but thepushevent can fire before GitHub's association index is ready.How to reproduce?
mainusing squash merge.release/v1.1.0-incubating.Direct Backport Pushworkflow run automatically on the merge commit.Resolve merged PR and green targetsstep may fail to find an associated PR and skippush-backports.Concrete example:
#460011d475a2d7406d012a95dd6909c53a13156ef5f5Version
1.1.0-incubating (Pre-release/Master)Commit Hash (Optional)
11d475a2d7406d012a95dd6909c53a13156ef5f5What browsers are you seeing the problem on?
N/A. This issue affects a GitHub Actions workflow rather than the browser UI.
Relevant log output
Additional context
A robust fix would be:
(#NNNN)pattern.commits/{sha}/pullswith retries and exponential backoff before giving up.