Repository navigation
decision(repo): default branch and Actions PR permission — two issues, no code in either #15834
Description
Activity
- added sub-issues
on Sep 6, 2026 Question 1 is decided; question 2 is still open, and it now gates the chosen fix.
- Q1 (default branch): the owner decided this on decision: the default branch is main, so Dependabot alerts, security-update PRs and scheduled workflows all read a branch no PR targets #16221 (11 Sep).
mainstays the default branch and is synced regularly fromDev_new_gui, which is neither 1A nor 1B. The implementation is ci(release): sync main from Dev_new_gui on a schedule, so scheduled workflows run current code #16246, in PR ci(release): open a weekly sync PR from Dev_new_gui into main, never merging it (#16246) #16263. - Q2 (may Actions open PRs): still open. The sync opens its PR with the optional
AUTOBOT_PUSH_TOKENsecret and falls back toGITHUB_TOKEN(the owner's token decision on ci(release): sync main from Dev_new_gui on a schedule, so scheduled workflows run current code #16246). Measured today, the repository has no Actions secrets, andcan_approve_pull_request_reviewsisfalse. So the fallback can't open the sync PR, the same way fix(ci): release changelog PR step fails — 'GitHub Actions is not permitted to create or approve pull requests', so no changelog has reached release since v0.5.1 #15167's changelog step fails.- Provisioning the token amounts to 2B for this workflow.
- Otherwise, only 2A unblocks it.
Details and the measurement are on #15318.
- Q1 (default branch): the owner decided this on decision: the default branch is main, so Dependabot alerts, security-update PRs and scheduled workflows all read a branch no PR targets #16221 (11 Sep).
Owner decision, 11 Sep 2026, Q2: neither 2A nor 2B. The sync is done by hand. "Allow GitHub Actions to create and approve pull requests" stays off, and no push token is provisioned for this repository. Consequence for #16246 / #16263: the weekly
sync-main-to-dev.ymlrun cannot open the sync PR. The script keeps #13973's behaviour: it warns, links the compare page, and exits 0. The owner opens each weekly sync PR by hand from that link. A PR a person opens starts its checks normally, so the parked-run problem (#16272) does not arise for it.CI_BOT_ATTRIBUTION.mdwill be corrected to say this. Q1 was decided earlier on #16221 (keepmain, sync regularly).- added a commit that references this issue
on Sep 11, 2026 Owner decision, 2026-09-11, extending the Q2 ruling: the weekly sync check may keep one tracking issue open. It exits 2 when it can't write that issue, so a reminder that fails to post shows as a red scheduled run instead of vanishing (
release_sync_main.py:574, #16263).- added a commit that references this issue
on Sep 11, 2026 Branch-freeze re-verification against current
origin/main(2026-09-20). Both tracked branches (issue-16246-sync-main,issue-16263-track) are already gone from origin.Q1 confirmed current:
gh api repos/mrveiss/AutoBot-AI --jq '.default_branch'returnsmain, matching the 2026-09-11 comment's #16221 decision.Q2 has two conflicting recorded owner decisions, 7 days apart, and I don't think either should be assumed current without a human resolving it:
- 2026-09-11 (comment above, this issue): "neither 2A nor 2B... 'Allow GitHub Actions to create and approve pull requests' stays off, and no push token is provisioned."
- 2026-09-18 (on the dependent issue, fix(ci): release changelog PR step fails — 'GitHub Actions is not permitted to create or approve pull requests', so no changelog has reached release since v0.5.1 #15167): "the owner will enable the repository setting... Allow GitHub Actions to create and approve pull requests" — this is 2A, the option the 09-11 decision explicitly rejected.
Current live state:
gh api repos/mrveiss/AutoBot-AI/actions/permissions/workflowstill returnscan_approve_pull_request_reviews: false— so as of right now, the 09-11 ruling ("stays off") is what's actually in effect, not the 09-18 intent. That could mean the 09-18 decision simply hasn't been executed yet, or that it supersedes 09-11 and execution is pending, or that I'm reading a stale comment against a decision that was later reconsidered. I can't tell which from the record alone, and it's a repository-administration setting only the owner can change — not something I'll toggle or guess about.Flagging this contradiction rather than picking a side. Someone with the full decision history (or the owner directly) should confirm which of the two rulings is current before #15167 is worked further — it changes what "done" looks like for that issue.
What would have to be true to close this — and tonight's evidence that it is not yet true
Found by a sweep for umbrellas whose native children are all closed (both of this one's are). It stays open, and there is now direct evidence for why.
The one thing missing: the Actions PR permission is still off
Screening #17728 tonight established that the weekly-durations
landjob fails with "GitHub Actions is not permitted to create or approve pull requests", and no PR has ever existed from it. That is the repository setting Allow GitHub Actions to create and approve pull requests — the permission half of this decision — still unflipped.To close: the setting is flipped and a bot-opened PR demonstrably exists from the job that could not create one. That is the artifact; a decision recorded without the setting changed leaves the symptom in place.
One distinction worth carrying into the flip
There are two adjacent settings, not one, and they are distinguished by whether a PR exists:
blocked thing the setting this issue / the landjobthe creation of the PR Allow GitHub Actions to create and approve pull requests #17728 the workflows on a PR that was created (#17723, 18 runs action_required)fork-PR approval policy, all_external_contributorsFlipping the creation setting unblocks
landand leaves #17723's runs held. Relaxing the fork policy does the reverse. Two flips, or one flip and a remaining defect — detail on #17728.Neither half is verifiable from here: repository settings need admin-visible state I cannot read, so the evidence above is the observable symptom, not the setting value.
One decision, two issues
Both are repository settings, not code. No pull request can close either, which is why both have
sat unstarted.
main's copy — 500 commits behindDev_new_gui; seven are stale there and the armed pip-audit gate has never run on current codeThe questions
1. Should
Dev_new_guibe the default branch? Schedules fire from the default branch. Every PRalready targets
Dev_new_gui, andmainis 500 commits behind, so today's scheduled security gatesrun code nobody ships.
2. May GitHub Actions open pull requests in this repository? The toggle that permits it also
permits Actions to approve PRs, which is why it is off.
Options
Dev_new_guithe default branchDev_new_gui;mainbecomes an explicit release pointermain, add explicitbranches:to each scheduleRecommendation
1A and 2B. 1A because a security gate that has never run on current code is not a gate, and every
other signal in the repository already treats
Dev_new_guias trunk. 2B because 2A trades a reviewcontrol for a convenience, and the sibling decision may be about to make that review control real.
What happens to the two
They become dependents. Each closes on the settings change plus a note recording the new state.