Skip to content

Fix the code-contribution fork fallback (v0.5.1) - #113

Merged
Barneyjm merged 1 commit into
mainfrom
fix/contrib-fork-fallback
Aug 24, 2026
Merged

Barneyjm merged 1 commit into
mainfrom
fix/contrib-fork-fallback

Conversation

@Barneyjm

Copy link
Copy Markdown
Owner

What broke

A runner hit this mid-task:

! code PR failed (gh repo exited 1: the `--remote` flag is unsupported when a
repository argument is provided) — submitting with code inline only

publishCodeContribution fell back to gh repo fork <repo> --remote --remote-name contribfork
whenever the direct push to the contrib repo was refused. gh rejects --remote outright when a
repository argument is present, so the fork step exited 1, the PR never opened, and the
contribution degraded to inline code only.

No volunteer work was lost — the inline copy is persisted server-side either way — but the
artifact_uri never became a PR URL.

The fix

Fork without touching remotes, then wire the fork up with plain git:

await run('gh', ['repo', 'fork', repo, '--clone=false'], dir);
const login = (await run('gh', ['api', 'user', '--jq', '.login'], dir)).trim();
await run('git', ['remote', 'add', 'contribfork', `https://github.com/${login}/${name}.git`], dir);
await run('git', ['push', '-u', 'contribfork', branch], dir);

The gh api user call moved ahead of the push, since the login now builds the remote URL.

Also: the direct-push error is no longer swallowed. Previously only the fork failure surfaced,
hiding why the push was refused. The runner now reports both causes:
direct push refused (…); fork fallback failed (…).

Verification

Against real gh 2.88.1 and real GitHub, using an upstream without push rights that was already
forked (so the fork step added nothing new):

  • Old form reproduces the reported error exactly, at flag validation.
  • git push -u originremote: Permission to rkbarney/justrss.git denied to Barneyjm (403), so
    the fallback genuinely triggers.
  • gh repo fork rkbarney/justrss --clone=falseBarneyjm/justrss already exists, exit 0.
  • git remote add contribforkgit push -u contribfork* [new branch].

head resolves to Barneyjm:contrib/…, exactly what gh pr create --head wants. Only
gh pr create was skipped, since it would open a PR on a third party's repo. Rehearsal branch
deleted afterward.

Notes

  • Version bumped to 0.5.1 (rides this PR, per convention). The lockfile root still said 0.4.0
    never bumped for 0.5.0 — so that drift is corrected here too.
  • Runners install via npx givework start, so this only reaches volunteers on release.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WoAJRWLbAW5pakUUzEzcjV

`gh repo fork <repo> --remote --remote-name contribfork` is rejected by gh:
"the --remote flag is unsupported when a repository argument is provided".
Runners hit this whenever the direct push to the contrib repo was refused,
so the PR never opened and the contribution degraded to inline code only.

Fork without touching remotes and wire the fork up with plain git instead.
Verified against real gh 2.88.1 + GitHub: direct push 403 -> gh repo fork
--clone=false -> git remote add contribfork -> push to the fork, all clean.

Also stop swallowing the direct-push error. Previously only the fork failure
surfaced, hiding why the push was refused in the first place; the runner now
reports both causes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WoAJRWLbAW5pakUUzEzcjV
@Barneyjm
Barneyjm merged commit 1e8ca18 into main Aug 24, 2026
6 checks passed
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