Conversation
…equest (#2504) * ci(repo): let the back-merge report why it cannot open its own pull request The first real run of back-merge.yml failed on the #2483 promotion with: pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest) My mistake. The job carries pull-requests: write, but that is overridden by 'Allow GitHub Actions to create and approve pull requests', which is off at both repository and organisation level. I verified the workflow's LOGIC against the real repository state and never verified the one thing it exists to do, which is that its token can actually open a pull request. That setting should stay off. It also lets a workflow APPROVE pull requests, so turning it on to fix a back-merge would open a larger hole than the one this job closes. So take a token if one is offered and explain the situation when it is not: - prefer BACKMERGE_TOKEN when the secret exists, falling back to GITHUB_TOKEN, and print which one is in use so a silent fallback is visible - on the specific refusal, print what is wrong, why the obvious setting change is the wrong answer, and the exact command to open it by hand - on any OTHER failure, report the real error rather than blaming the setting Exercised all four paths against a stubbed gh: refusal exits 1 with the guidance, an unrelated failure exits 1 with its own message and does not mention settings, success with a PAT exits 0, and the already-holds no-op is what the live run did. #2503 carries the back-merge this run should have opened. Refs #2393 * ci(repo): do not re-lint main's history on a back-merge pull request #2503, the back-merge this workflow should have opened, failed 'Validate commit messages' on: chore(deps): bump json (#2131) scope must be one of [backend, frontend, ...] [scope-enum] Scope 'deps' is not in the enum. That is the Dependabot commit merged straight into main on 2026-08-13 - the incident that made back-merges necessary in the first place - so the back-merge fails on the very commit it exists to carry back. The job already exempts the promotion direction for this exact reason: a dev to main pull request replays already-merged history and re-lints commits that shipped long ago and cannot be rewritten. A back-merge is the same thing in the opposite direction and was simply not covered. Exempt base dev + head main symmetrically. Verified the condition still distinguishes all four directions: promotion skips, back-merge skips, an ordinary branch into dev or main still lints, and the dependabot exemption is unchanged. Refs #2393 --------- Co-authored-by: Ankit Upadhyay <ankit@dunexploration.com>
chore(repo): back-merge main into dev
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
|
|
|
This was referenced Aug 25, 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
1 participant
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.
PR Checklist
What is the current behavior?
mainis 2 commits behinddev, and both are workflow fixes that only take effect once they are ONmain.#2504added two things:back-merge.ymlnow prefers aBACKMERGE_TOKENwhen present and, when refused, explains thatGITHUB_TOKENcannot open pull requests here rather than dying on a raw GraphQL error.pr-governance.ymlexempts the back-merge direction (base: dev,head: main) from re-linting commit messages, matching the exemption that already existed fordevtomainpromotions.The second one does not work until
maincarries it. Forpull_requestevents GitHub reads the workflow definition from the HEAD branch, and a back-merge's head ISmain. Verified empirically: a fresh run after #2504 merged (32855397093) still executed the job and failed onchore(deps): bump json (#2131), so #2503 had to be merged with an explicit admin bypass.This promotion is what makes the exemption real, so the next back-merge does not need that bypass.
What is the new behavior?
Nothing at runtime. The whole diff is:
apps/orpackages/Deploy notes
No API deploy is needed. Production is already running
1adfd8064, and this carries no backend code and no migrations, so the running API is unaffected.cd-frontend.yamlfires on push tomain, but itsdetect-frontendjob gates the deploy on affected paths and nothing frontend changed here, so it should self-skip. Worth a glance at the run afterwards rather than an assumption.Related Issue(s)
Refs #2393