Fixed next branch push rejected by the stable-branch ruleset - #58
Merged
Merged
Conversation
The push landed as `github-actions[bot]` -- the credential `actions/checkout` persists from the default `GITHUB_TOKEN`. That identity is not on the bypass list of the "Restrict stable branch creation/updates" ruleset, which went active on 2026-09-04 and matches `X.Y-next` as well as the stable branches themselves. Only repo admins, `@ibexa/quality-assurance`, `@ibexa/php-dev`, `@ibexa/javascript-dev` and the `Ibexa Workflow Automation #1` App may bypass it, so every run since has failed with GH013. Generated an installation token for that App and passed it to `actions/checkout`, so the persisted credential -- and therefore the push -- uses the exempt identity. The commit identity moves to the App's own bot user; its numeric ID is resolved at runtime so the noreply address survives a rename of the App. Same pattern as `ibexa/gh-workflows/.github/workflows/upmerge.yml`.
The fleet-wide GHA standardization (#57) is based on 4.6, where `build-next-branch.yaml` does not exist, so this workflow falls through its net and keeps the old pins after the merge up. `actions/checkout@v4` also still targets the deprecated Node 20. Versions match the bundle-generator skeleton.
|
alongosz
requested review from
GrabowskiM,
OstafinL,
Steveb-p,
ViniTou,
albozek,
alekmick,
barw4,
bnowak,
ciastektk,
dew326,
konradoboza,
mikadamczyk,
tbialcz,
tischsoic and
wiewiurdp
September 7, 2026 11:15
bnowak
approved these changes
Sep 7, 2026
dew326
approved these changes
Sep 7, 2026
albozek
approved these changes
Sep 7, 2026
konradoboza
approved these changes
Sep 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Related PRs:
Description:
"Prepare next branch" stopped landing on 2026-09-04, when the
Restrict stable branch creation/updatesruleset went active: run 33881442848 (6.0), run 33881441213 (5.0).The ruleset's
ref_namepattern is fnmatch, not regex, sorefs/heads/[0-9]*\.[0-9]*matchesX.Y-nexttoo.GET /repos/ibexa/admin-ui-assets/rules/branches/6.0-nextreports the same four rules as for6.0. That's fine, those branches are worth protecting.The actual problem is the push identity. It goes out as
github-actions[bot], the credentialactions/checkoutpersists from the defaultGITHUB_TOKEN, and that identity is not on the bypass list. Repo admins,@ibexa/quality-assurance,@ibexa/php-dev,@ibexa/javascript-devand theIbexa Workflow Automation #1App are. The App was already dispatching these runs, it just never did the push.Ibexa Workflow Automation #1installation token and passed it toactions/checkout, so the persisted credential, and therefore the push, uses the exempt identity. Same pattern asibexa/gh-workflows/.github/workflows/upmerge.yml.gh api /users/<app-slug>[bot]at runtime, so the noreply address survives a rename of the App.actions/checkoutto v7 and setruns-ontoubuntu-26.04, matching the bundle-generator skeleton.Note
The
[GHA]bump is here and not in #57 because that one is based on4.6, wherebuild-next-branch.yamldoesn't exist. Workflows living only on 5.0+ fall through the net of a 4.6-based standardization wave.Needs a merge up to
6.0. The workflow file is byte-identical on both branches, so it should be clean.For QA:
No QA required. Verification is a
workflow_dispatchof "Prepare next branch" on5.0and6.0after the merge up, confirming the push to5.0-next/6.0-nextlands.Documentation:
No documentation required.
🤖 Generated with Claude Code