Conversation
The factory reusable fetches origin/stable and fails when the branch does not exist, opening ci: testing→main promotion conflict. Create stable from main on first run so fresh forks can promote without a manual stable branch. Assisted-by: grok-4.6 via opencode
df99852 to
ea51249
Compare
[scanner] CI root cause: this is a fork PR, so
|
Red check root cause (not your PR's content)
Filed as a finpilot issue with two recommended fixes. The repo-side fix (skip enforcement on fork PRs) is prepared but I cannot push it — the hive GitHub App lacks the --- a/.github/workflows/label-enforcement.yml
+++ b/.github/workflows/label-enforcement.yml
@@ jobs:
enforce:
+ # Fork PRs get a read-only GITHUB_TOKEN; the reusable workflow's label
+ # write then 403s and hard-fails the check. Skip enforcement there.
+ if: github.event_name == 'issues' || github.event.pull_request.head.repo.full_name == github.repository
uses: projectbluefin/actions/.github/workflows/reusable-design-enforcement.yml@ce7ab75eb66d3ace300fed4c121a31b417e8f9fescanner agent (ACMM L5 — hold-gated mode)🐝 Hive Agent: — hive: agent=scanner backend=copilot model=kimi-k3 |
[scanner] CI root cause: this is a fork PR, so
|
[scanner]
|
|
[scanner] scanner agent (ACMM L5 — hold-gated mode)🐝 Hive Agent: — hive: agent=scanner backend=copilot model=kimi-k3 copilot=1.0.78 |
hanthor
left a comment
hanthor
left a comment
There was a problem hiding this comment.
Sound idea, but stale base, a failing check, and it now collides with two other open PRs
What is good
The problem is real and well-described: the factory reusable fetches origin/stable and dies with exit 128 when the branch does not exist, which is a genuine first-fork papercut for a template repo. Creating it idempotently from main is the right shape, the git ls-remote --exit-code --heads guard is correct (inside an if, so set -e does not fire on the exit-2 "not found" case), and the docs in SETUP_CHECKLIST.md and the onboarding skill were updated to match the new behaviour rather than left to rot. Gates are clean — merged into origin/main @ 1db684b: bats tests/unit 180/180, just lint 0, just check 0, same as baseline.
1. Your enforce check is failing
Job 101876916497, conclusion failure:
Error: PUT /repos/projectbluefin/finpilot/issues/334/labels: 403
{"message":"Resource not accessible by integration","status":"403"}
This is not your fault and nothing in this PR can fix it. The granted token was Issues: read / PullRequests: read — GitHub downgrades the token to read-only for pull_request events from forks, regardless of the issues: write the workflow declares. Every fork PR in this repo hits it. #351 fixes it by switching that workflow to pull_request_target. Flagging it so the red check is not mistaken for a defect here, and so whoever merges knows it will stay red until #351 lands.
2. The base is 17 commits behind
$ git rev-list --count $(git merge-base origin/main pr/334)..origin/main
17
It still merges cleanly into current main — I verified with git diff --name-only --diff-filter=U returning nothing — but the diff is written against promote-main-to-stable.yml as it looked at 74c182b, which is why the collisions below happen.
3. It conflicts with both other PRs touching this file
combo [341 334]: CONFLICT at pr/334 -> .github/workflows/promote-main-to-stable.yml
combo [334 329]: CONFLICT at pr/329 -> .github/workflows/promote-main-to-stable.yml, AGENTS.md
Three open PRs (#329, #334, #341) all edit promote-main-to-stable.yml and any two of them conflict. #341 is the cheapest and most mechanical (a pure projectbluefin/actions digest bump across seven call sites, SHA verified against upstream). Landing #341 first and rebasing this on top is the lowest-friction ordering.
4. Two small things while you are rebasing
fetch-depth: 0 is unnecessary and expensive. The job does one git ls-remote and one git push origin HEAD:stable. Neither needs full history — HEAD:stable pushes the single checked-out commit. On a repo with 100+ commits this clones everything on every push to main, forever, to answer a question that git ls-remote could answer with no checkout at all. Consider dropping fetch-depth entirely, or restructuring so the checkout only happens inside the "branch is missing" path.
The job runs on every push to main for the rest of the repo's life to check a condition that can only be true once. That is a ~20s runner job per merge. A continue-on-error-style guard, or moving this into the promote job itself, would avoid the permanent tax. Not blocking — just noting that a one-time bootstrap has been implemented as a permanent step.
Worth confirming: if a repo protects stable with a ruleset matching by name pattern, a push to a not-yet-existing stable from GITHUB_TOKEN can still be rejected by branch-creation restrictions. Worth one line in the job explaining what the operator should do if git push origin HEAD:stable 403s, since the whole point of this change is to smooth the first-run experience.
Generated by Claude Code
|
[scanner] CI root cause: the Fix already open: #351 (switches label-enforcement to scanner agent (ACMM L5 — hold-gated mode)🐝 Hive Agent: — hive: agent=scanner backend=copilot model=kimi-k3 copilot=1.0.78 |
[scanner] The
|
3 participants
The factory reusable fetches origin/stable and fails when the branch does not exist, opening ci: testing→main promotion conflict. Create stable from main on first run so fresh forks can promote without a manual stable branch.
Assisted-by: grok-4.6 via opencode