This is an automated email from the ASF dual-hosted git repository.
github-merge-queue[bot] pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/texera.git
The following commit(s) were added to refs/heads/main by this push:
new 279e12b2cd fix(ci): stop cancelling in-progress Backport Approvals
runs (#8523)
279e12b2cd is described below
commit 279e12b2cd469c5cadaf69d987513f9b2552e2e6
Author: Meng Wang <[email protected]>
AuthorDate: Mon Sep 21 05:49:34 2026 +0000
fix(ci): stop cancelling in-progress Backport Approvals runs (#8523)
### What changes were proposed in this PR?
`Backport Approvals` is a required status check on `main`, and GitHub
evaluates the LATEST check run with that name. The workflow's
concurrency group had `cancel-in-progress: true`, so when two PR events
land close together (a push right after a review request or a label
change), the newer run cancels the older one — and when the older run's
"cancelled" terminal state is recorded after the newer run's success,
the required check reads as failed and the merge button is blocked. This
happened on #8516: the check showed a cancelled run as its latest state
while a sibling run of the same commit had already passed; re-running
the cancelled run unblocked the merge.
The job completes in seconds, so cancellation saves nothing. This stops
cancelling the in-progress run (`cancel-in-progress: false`). GitHub
still keeps at most one pending run per concurrency group and replaces
it on a newer event, but a replaced pending run is cancelled before its
successor even starts, so its cancelled state can never land last: the
latest check run on the commit always ends as a real verdict. A skipped
intermediate evaluation loses nothing, because the job reads the live
labels and reviews at run time rather than the event payload.
### Any related issues, documentation, discussions?
Closes #8522. Observed on #8516 (a cancelled `Backport Approvals` run
blocked an otherwise green merge).
### How was this PR tested?
Config-only change to the workflow's concurrency setting; no executable
code path changes. Verified the failure mechanism on #8516: the blocked
merge showed the cancelled run as the latest `Backport Approvals` check
run, and re-running it (6s pass) unblocked the merge immediately.
### Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (Claude Fable 5, Anthropic). Reviewed by
the author before submission.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Fable 5 <[email protected]>
---
.github/workflows/backport-approval-check.yml | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/.github/workflows/backport-approval-check.yml
b/.github/workflows/backport-approval-check.yml
index f37a52505c..6f92f08935 100644
--- a/.github/workflows/backport-approval-check.yml
+++ b/.github/workflows/backport-approval-check.yml
@@ -58,7 +58,15 @@ permissions:
concurrency:
group: backport-approvals-${{ github.event.pull_request.number || github.ref
}}
- cancel-in-progress: true
+ # Never cancel the run in progress: this is a required status check, and
GitHub
+ # takes the LATEST check run with this name -- a cancelled in-progress run's
+ # terminal state can land after a newer run's success (the job is seconds
long)
+ # and block the merge as a failed required check. GitHub still keeps at most
one
+ # pending run per group and replaces it on a newer event, but a replaced
pending
+ # run is cancelled before its successor even starts, so the last word on the
+ # commit is always a real verdict. A skipped intermediate event loses
nothing:
+ # the job reads the live labels and reviews at run time, not the event
payload.
+ cancel-in-progress: false
jobs:
backport-approvals:
