Repository navigation
Backport fast path has been dead since 2026-07-24: direct pushes to release/* are rejected by the ruleset #8377
Description
What happened?
Direct Backport Push cherry-picks a cleanly-applying fix straight onto the release branch and pushes it. Since release/* was brought under the Merge Queue ruleset, every one of those pushes is rejected:
remote: error: GH013: Repository rule violations found for refs/heads/release/v1.3.
remote: - Changes must be made through the merge queue
remote: - Changes must be made through a pull request.
remote: - 3 of 3 required status checks are expected.
! [remote rejected] HEAD -> release/v1.3 (push declined due to repository rule violations)
It retries five times and fails. Latest occurrence: run 33706287941 on #8347.
The last direct push that succeeded onto release/v1.2 was 2026-07-24 (9a989b4bd). Nothing has landed that way since.
The counterintuitive part is that the cleaner the backport, the more certain it is to be lost. The conflict path opens a PR and still works — which is why nearly everything that has reached release/v1.2 in the last six weeks arrived as a backport PR someone finished by hand.
It is not silent: the job goes red, a comment lands on the original PR, and a red backport/<branch> commit status is set. But the original PR is already merged by then and nobody watches the Actions tab, so it went unnoticed for six weeks.
Fixes lost this way — on main, not on release/v1.2, with nothing tracking them:
- fix(frontend): raise ng serve heap limit to avoid OOM on low-RAM machines #6914
fix(frontend): raise ng serve heap limit - fix(deps): bump hono from 4.12.31 to 4.13.1 in /frontend #7587
fix(deps): bump hono - fix(deps): bump js-yaml from 4.2.0 to 4.3.1 in /frontend #7588
fix(deps): bump js-yaml - fix(frontend): use singular relative time units #8110
fix(frontend): use singular relative time units - fix(amber): declare cloudpickle in LICENSE-binary-python #8293
fix(amber): declare cloudpickle in LICENSE-binary-python— the CI license-drift fix itself, sorelease/v1.2still carries that problem
How to reproduce?
- Merge a
fix:PR intomaincarrying arelease/*label whose cherry-pick applies cleanly onto that branch. - Watch
Direct Backport Pushfor that push:Discover direct backport targetssucceeds, thenbackport #N to release/vX.Yfails ongit pushwithGH013. - The fix is on
mainand never reaches the release branch, while the label on the merged PR still says it did.
Version/Branch
main
Activity
fix(ci): open a pull request for a clean backport instead of pushing it
fix(ci): open a pull request for a clean backport instead of pushing it
ci: give GitHub Actions bypass on the release-branch ruleset
ci: give GitHub Actions bypass on the release-branch ruleset
ci: give GitHub Actions bypass on the release-branch ruleset (apache#…
mengw15 commentedon Sep 21, 2026
Reopening: #8379 did not take effect.
The ruleset was never created. asfyaml has rejected it on every push to main since #8379 merged — 38 mails to
commits@, the first 49 seconds after the merge, the most recent 2026-09-21 06:01 UTC:(the first one.)
GET /repos/apache/texera/rulesetsstill returns the four rulesets from before #8379, withMerge Queuestill coveringrelease/v1.1,v1.2andv1.3andupdated_atat 2026-09-01. The fail-safe ordering held and nothing was left uncovered — but the abort takes the wholegithub:feature of.asf.yamlwith it, so none of it has been applied since 2026-09-11.One line of this issue is no longer true. It says "It is not silent: the job goes red, a comment lands on the original PR." That stopped on 2026-09-11: #8379 narrowed the
push-backportsjob toactions,contents,issuesandstatuses, and commenting on a pull request is scoped bypull-requests, notissues. The annotation step now takes four 403s and gives up with a warning, leaving the step green.It shows in the record — the 2026-09-03 failures commented ("Backport to
release/v1.3failed. See job log."); #8432, #8494 and #8562 did not, and went unnoticed until the v1.3 audit.Lost since this was filed, all
release/v1.3:Each was verified absent by reverse-applying its patch against
release/v1.3, not by grepping commit messages — a message grep gives false positives, e.g. #8550's body mentions "e.g. #8432". Backport PRs are now open for all five: #8619, #8620, #8621, #8622, #8623.In flight. #8624 reverts #8379. #8626 routes a clean backport through a pull request instead, the way the conflicted ones already go — #8378 proposed the same thing with the workflow performing the close/reopen and arming auto-merge itself; those are the parts that can only be proven in production, so #8626 leaves them to the release manager's own click. This issue stays open until #8626 lands.
revert: "ci: give GitHub Actions bypass on the release-branch ruleset" (
ci: open a pull request for a clean backport instead of pushing it (a…