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:
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
What happened?
Direct Backport Pushcherry-picks a cleanly-applying fix straight onto the release branch and pushes it. Sincerelease/*was brought under the Merge Queue ruleset, every one of those pushes is rejected:It retries five times and fails. Latest occurrence: run 33706287941 on #8347.
The last direct push that succeeded onto
release/v1.2was 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.2in 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 onrelease/v1.2, with nothing tracking them:fix(frontend): raise ng serve heap limitfix(deps): bump honofix(deps): bump js-yamlfix(frontend): use singular relative time unitsfix(amber): declare cloudpickle in LICENSE-binary-python— the CI license-drift fix itself, sorelease/v1.2still carries that problemHow to reproduce?
fix:PR intomaincarrying arelease/*label whose cherry-pick applies cleanly onto that branch.Direct Backport Pushfor that push:Discover direct backport targetssucceeds, thenbackport #N to release/vX.Yfails ongit pushwithGH013.mainand never reaches the release branch, while the label on the merged PR still says it did.Version/Branch
main