fix(ci): point the deploy at the bitbaum org, so this repo can ship again - #227
Merged
Conversation
…gain deploy.yml called catomean/fleetcrown/.github/workflows/selfhost-deploy.yml. The Actions `uses:` resolver does not follow a rename or a transfer, though the REST API and git both do — so the reference looked correct everywhere it could be checked, while the run died before any job started. This repo has no auto-merge.yml, so nothing here ever went visibly red; the deploy simply stopped happening. Found by auditing every workflow reference in the org against the canonical full_name REST reports. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvjGNAS9CMfEGNW26tUR4P
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 29, 2026
…231) PR #227 moved the deploy workflow to the bitbaum org but left two incident notes in auto-merge-sweep.sh pointing at catomean/ repo paths that no longer resolve. The comments are the only record of why the sweep skips red bases and merges oldest-first, so a dead path there costs a future reader the receipt. Found because local main had diverged: it carried this half of the rename in a commit whose deploy.yml half shipped as #227. Claude-Session: https://claude.ai/code/session_01TDhA9vfTasuixhGQ2NVmcE Co-authored-by: Mao Nakamoto <41178744+maonakamoto@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <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