fix(ci): point Actions at the bitbaum org, so merges and deploys resume - #800
Merged
Conversation
The fleet moved to the bitbaum org. Actions' `uses:` resolver does not follow a repo transfer — unlike the REST API, `git clone` and `git push`, which all do. So every reference here still looked correct to every tool that could be used to check it, while the runs died before a single job started: zero jobs, no logs, and a bare "workflow file issue". That failure mode is invisible in the usual places. A PR shows CLEAN and MERGEABLE with no red check, because the workflow that would have reported the red never ran. Nothing is marked broken; work simply stops moving. Files changed: auto-merge.yml Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P
gitleaks-action is free for PERSONAL accounts only. Under an organization it refuses to scan and exits "missing gitleaks license", so moving this repo into bitbaum turned secret scanning off while leaving the job, its name, and its place in the checks list exactly as they were. It failed loudly here only because the licence check errors. A wrapper that had skipped instead would have reported green while scanning nothing — and the comment above the step still read "Free for public repos; no license needed", so the file asserted the opposite of what was happening. Replaced with the gitleaks CLI, which is MIT and unaffected. Same scope as before: the incoming commit range, not full history (~173 pre-existing 2025-era findings live there and only a history rewrite clears them). Verified against 8.30.1 before writing it, because a secret scanner is exactly the kind of check that is trusted without ever being watched: - clean range -> exit 0 - planted sk-ant key -> exit 1, "leaks found" - EMPTY range -> exit 0, scans nothing, reports success That last one is why the step counts commits itself and fails on zero. A scanner that silently reads no commits is worse than one that is obviously broken, because it keeps reporting green. Note the first mutation attempt did NOT go red: it planted AWS's published EXAMPLEKEY, which gitleaks allowlists by design. The test was wrong, not the scanner. A mutation that stays green is a hole in the test. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P
This was referenced Aug 28, 2026
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 28, 2026
…me (#803) Twice in two days an owner change stopped every merge and every deploy in this repo: `maonakamoto` → `catomean` on 2026-08-26, then the move to the `bitbaum` org, fixed in #800. Each fix pointed at a name that became a redirect the next time. Both outages were invisible in every place anyone looks. GitHub redirects a renamed owner for the REST API and for git remotes, so `gh api` answers and `git push` works; the Actions resolver is the one consumer that does not follow the redirect. It fails before any step exists, with "This run likely failed because of a workflow file issue" and no readable log, while pull requests stay green, clean and mergeable. The red run is on main, under a workflow nobody opens. Work simply stops shipping. Two instances is where the rule says stop fixing instances. This asks the REST API what each referenced repo is really called and fails when that disagrees with what the workflow says — that disagreement IS the bug, because REST resolves the redirect and Actions does not. A static allowlist could not catch it: after a rename the workflow file and the allowlist would both hold the same stale name and agree with each other. Only asking GitHub what the repo is called today can tell. Lives in CI rather than in `npm run verify`, which is the offline SSOT bundle and must stay deterministic; without a token this skips rather than passing quietly. A non-200 that is not a 404 exits 2 — could-not-look is never reported as looks-fine. Proven by mutation: restoring `catomean/dotfiles` fails with the canonical name to use. Also fixes the last CLAUDE.md reference to the 2026-08-26 owner. Claude-Session: https://claude.ai/code/session_012dpTLxh5GJWeWTF1UEvcD5 Co-authored-by: Georgy Butaev <41178744+g-but@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
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.
The fleet moved to the
bitbaumorg, and Actions'uses:resolver does not follow a repo transfer.That is the whole bug, and its danger is that every tool available to check it disagrees with the runner.
gh api repos/catomean/dotfilesreturns the repo.git cloneworks.git pushworks. All of them follow the redirect. Theuses:resolver alone does not — so the reference reads as correct everywhere except the one place it is consumed.What it looks like when broken
Not a red check. Zero jobs, no logs, and a bare "This run likely failed because of a workflow file issue." The workflow that would have reported a failure is the one that could not start.
Downstream, a PR sits at
CLEAN/MERGEABLEwith nothing marked wrong. Nothing announces an outage; work just quietly stops moving. In this fleet that had already accumulated 11 clean unmerged dependabot PRs in orangecat and 8 in reparaturbonus-zh before anyone noticed.Why this repo, now
bitbaum/fleetcrownhit the same failure and fixed it in #415; this applies the identical change here. Two owners appear across the fleet —maonakamoto(never repaired after the user rename) andcatomean(repaired for the rename, then broken again by the org transfer). Both resolve tobitbaumnow.Scope is
.github/workflows/only — those are the references that actually break a run. Docs naming the old owner are stale but not load-bearing, and rewriting them in bulk across 15 repos would be a large unverifiable diff attached to an outage fix.Verification
The honest check is not that CI passes — CI passing is compatible with the sweep still being dead, which is exactly how this went unnoticed. It is that the auto-merge run produces jobs instead of zero, which can only be observed after this lands on the default branch. I am watching for that on each repo rather than treating the merge as the finish line.
🤖 Generated with Claude Code
https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P