fix(ci): point Actions at the bitbaum org, so merges and deploys resume - #11
Merged
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 deploy.yml Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P
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