Backport fast path has been dead since 2026-07-24: direct pushes to release/* are rejected by the ruleset

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, so release/v1.2 still carries that problem

How to reproduce?

Merge a fix: PR into main carrying a release/* label whose cherry-pick applies cleanly onto that branch.
Watch Direct Backport Push for that push: Discover direct backport targets succeeds, then backport #N to release/vX.Y fails on git push with GH013.
The fix is on main and never reaches the release branch, while the label on the merged PR still says it did.

Version/Branch

main

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 (apache#…

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:

Validation failed while creating ruleset 'Merge Queue (release)':
['Actor GitHub Actions integration must be part of the ruleset source or owner organization']

(the first one.) GET /repos/apache/texera/rulesets still returns the four rulesets from before #8379, with Merge Queue still covering release/v1.1, v1.2 and v1.3 and updated_at at 2026-09-01. The fail-safe ordering held and nothing was left uncovered — but the abort takes the whole github: feature of .asf.yaml with 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-backports job to actions, contents, issues and statuses, and commenting on a pull request is scoped by pull-requests, not issues. 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.3 failed. 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:

source	merged	run
#8343	09-03	33705892851
#8347	09-03	33706287941
#8432	09-17	35187408300
#8494	09-18	35293784997 — CVE-2026-88057
#8562	09-18	35305278774

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…

Navigation Menu

Repository navigation

Backport fast path has been dead since 2026-07-24: direct pushes to release/* are rejected by the ruleset #8377

What happened?

How to reproduce?

Version/Branch

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Backport fast path has been dead since 2026-07-24: direct pushes to release/* are rejected by the ruleset #8377

Description

What happened?

How to reproduce?

Version/Branch

Activity

mengw15 commented on Sep 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions