mengw15 opened a new pull request, #8378: URL: https://github.com/apache/texera/pull/8378
### What changes were proposed in this PR? Direct Backport Push cherry-picked a cleanly-applying fix onto the release branch and pushed it. Since `release/*` came under the Merge Queue ruleset, every one of those pushes is rejected — `GH013: must go through a pull request, through the merge queue, three required status checks expected` — and the job retries five times and fails. The last one that landed was 2026-07-24. Five fixes are on `main` and not on `release/v1.2` because of it (#8377). The cleaner the backport, the more certainly it was lost: the conflict path opens a pull request and kept working, so almost everything that reached a release branch in the last six weeks arrived that way. This routes both outcomes through a pull request. That is also what ASF policy asks for — [an automated service must not push to a branch subject to official release without prior authorization from Infrastructure](https://infra.apache.org/github-actions-policy.html) — so a backport now travels the way every other change to a release branch travels. The two are not the same pull request: | | conflicted (unchanged) | clean (new) | | --- | --- | --- | | state | draft, for its author to finish | **ready for review** | | auto-merge | off | **armed (squash)** | | what is left | resolve conflicts, mark ready | **the release manager's approval** | A clean backport needs nobody's hands: it cherry-picked without conflicts, the backported tree built green before the original merged, and that manager already approved the original for this branch. The body and status comment say exactly that, so the approval is a confirmation rather than a second review. **Why a clean one is closed and reopened.** Both open as `github-actions[bot]`, and GitHub suppresses workflow runs for anything `GITHUB_TOKEN` does — so neither starts with any checks. A draft can afford that, since CI fires when its author pushes a resolution. A clean one cannot: nobody is going to push anything, its three required contexts would never appear, and auto-merge would wait on them forever, looking like progress while standing still. Closing and reopening it under `AUTO_MERGE_TOKEN` emits `pull_request: reopened`, which `Required Checks`, `Check License Headers` and `Validate PR title` all subscribe to, and leaves the bot as the pull request's author. Reopening is the half that must not be lost, since a backport left closed is a fix silently dropped. It retries, and if it still fails it says so on the original PR and fails the job rather than leaving a closed pull request nobody is watching. If auto-merge cannot be armed afterwards, the backport PR gets a comment correcting the claim its own body already made, so a reviewer does not approve and then wait for a merge that never comes. `push_entries` is now always empty, which leaves the `push-backports` job unreachable. Removing it is deliberately left to a separate change, so that this one is a behaviour change and that one is a pure deletion. ### Any related issues, documentation, discussions? Closes #8377. ### How was this PR tested? The routing was driven locally: with both targets clean, one clean and one conflicted, and both conflicted, `push_entries` comes out empty in every case while the clean targets carry `clean: "true"` and the conflicted ones `clean: "false"`. Mislabelling a clean target turns that run red, so the check is not vacuous. The workflow parses as YAML, every embedded `github-script` body passes `node --check`, and `release_branches.py` still parses the annotated config. **Not verifiable off GitHub**, and worth watching on the first clean backport after this lands: that the close/reopen actually starts the three required checks, and that auto-merge is accepted on the reopened pull request. Both failure modes are handled rather than assumed — a failed reopen reports on the original PR and fails the job, a failed arming comments on the backport PR — but neither path has executed in production. The evidence for the diagnosis itself is in #8377: [run 33706287941](https://github.com/apache/texera/actions/runs/33706287941/job/100496019398) shows the `GH013` rejection, and `9a989b4bd` on `release/v1.2` is the last push that succeeded. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-5) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
