Skip to content

fix(v1.27 migration): qualify repo with owner so gh rename actually runs#1437

Open
agile-operators wants to merge 1 commit into
garrytan:mainfrom
agile-operators:fix/v1.27-migration-repo-rename-owner-qualified
Open

fix(v1.27 migration): qualify repo with owner so gh rename actually runs#1437
agile-operators wants to merge 1 commit into
garrytan:mainfrom
agile-operators:fix/v1.27-migration-repo-rename-owner-qualified

Conversation

@agile-operators
Copy link
Copy Markdown

@agile-operators agile-operators commented May 11, 2026

Summary

The v1.27.0.0 migration (gstack-brain → gstack-artifacts rename) silently fails to rename users' GitHub repos because it passes a bare repo name to gh repo rename --repo and gh repo edit, both of which require the [HOST/]OWNER/REPO form.

$ gh repo rename gstack-artifacts-Brandon --repo gstack-brain-Brandon --yes
expected the "[HOST/]OWNER/REPO" format, got "gstack-brain-Brandon"

Because stderr was suppressed with 2>/dev/null, this surfaced only as the generic warning gh rename failed (repo may not exist or permission denied) — misdirecting users who actually have ADMIN on the repo. The step is then mark_done'd, so a second /gstack-upgrade run does not retry. The local pointer at ~/.gstack-artifacts-remote.txt ends up referencing a repo that doesn't exist on GitHub until the user notices.

I hit this today upgrading from v1.26.4.0 → v1.32.0.0 on a fully-authenticated gh with ADMIN on the legacy gstack-brain-$USER repo.

What this PR changes

  • Resolve the authenticated user's login via gh api user --jq .login.
  • Qualify both the existing-name check (gh repo view) and the rename/edit invocations with $OWNER/$REPO.
  • Capture stderr from each attempt so the warning prints the real gh error instead of a generic guess.
  • Extend the fake gh mock in test/migrations-v1.27.0.0.test.ts so existing tests still drive the rename path with the new gh api user call.

No behavior change for users where the migration would already be a no-op (gh unauthenticated, repo already at the new name, or no legacy state).

Test plan

  • bun test test/migrations-v1.27.0.0.test.ts — 11/11 passing locally
  • bash -n gstack-upgrade/migrations/v1.27.0.0.sh — clean
  • Manually re-ran corrected command on my repo (gh repo rename gstack-artifacts-Brandon --repo agile-operators/gstack-brain-Brandon --yes) — succeeded

🤖 Generated with Claude Code


View in Codesmith
Need help on this PR? Tag @codesmith with what you need.

  • Let Codesmith autofix CI failures and bot reviews

`gh repo rename --repo` and `gh repo edit` both require the
"[HOST/]OWNER/REPO" form. The v1.27.0.0 migration was passing a bare
repo name (e.g. `gstack-brain-Brandon`), which `gh` rejects with:

  expected the "[HOST/]OWNER/REPO" format, got "gstack-brain-Brandon"

Both invocations suppressed stderr with `2>/dev/null`, so the failure
surfaced only as the generic "repo may not exist or permission denied"
warning — misdirecting users who actually have ADMIN on the repo.
The step was then `mark_done`'d, so re-running the upgrade does not
retry. The local pointer at ~/.gstack-artifacts-remote.txt ends up
referencing a non-existent repo until the user notices.

Reproduction (before fix):

  $ gh repo rename gstack-artifacts-Brandon --repo gstack-brain-Brandon --yes
  expected the "[HOST/]OWNER/REPO" format, got "gstack-brain-Brandon"

Fix: resolve the authenticated user's login via `gh api user --jq .login`
and qualify both the existing-repo check (`gh repo view`) and the
rename/edit calls. Capture stderr from each attempt so the warning
includes the real `gh` error instead of a generic guess.

The fake-gh test fixture grows a single case for `gh api user` so the
existing test matrix continues to drive the rename path.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant