Fix PR checkout to support fork PRs

[Tsuesun]

Use GitHub's PR refs (pull/NUMBER/head) instead of fetching branch by name. This works for both same-repo and fork PRs because GitHub automatically creates these refs in the base repository for all PRs.

The branch name doesn't exist on origin for fork PRs, causing:
fatal: couldn't find remote ref

Using pull/${entityNumber}/head:${branchName} fetches the PR head and creates a local branch with the correct name.

Fixes issues with tag mode failing on fork PRs.

[izaitsevfb]

this looks correct

[izaitsevfb]

@ashwin-ant @chrislloyd, sorry for the direct ping, but this fix is blocking PyTorch's adoption of claude-code-action, as we rely heavily on fork PRs from external contributors.

Would appreciate a review if possible.

see also: #821

[ashwin-ant]

Has this been tested on a branch?

[izaitsevfb]

Has this been tested on a branch?

good question. tested it just now. it works with a caveat.

In the case when the forked branch name doesn't exist in the upstream repo everything works:

This is an open PR, checking out PR branch...
PR #52: 1 commits, using fetch depth 20
From https://github.com/pytorch/ciforge
 * [new ref]         refs/pull/52/head -> izaitsevfb-patch-1
Switched to branch 'izaitsevfb-patch-1'
Successfully checked out PR branch for PR #52
Configuring git authentication for non-signing mode

however, if the forked branch conflicts with the branch in original repo, it fails (in this example using main branch):

This is an open PR, checking out PR branch...
PR #51: 2 commits, using fetch depth 20
fatal: refusing to fetch into branch 'refs/heads/main' checked out at '/home/runner/work/ciforge/ciforge'
Error: Prepare step failed with error: Command failed: git fetch origin --depth=20 pull/51/head:main

the currently working case of non-forked PRs still work as before.

@ashwin-ant, in the current state it's better than nothing (e.g. for PyTorch 90+% all of the forked PRs would work vs 0% currently), but if you think that's not enough I could create another PR with a proper fix (like, generating unique branch names for forked PRs that are guaranteed to not conflict)

please let me know your thoughts.

[ashwin-ant]

Actually, does this allow the fork repo to make use of the source repo's ANTHROPIC_API_KEY? That's probably not something most open source repos would want.

[izaitsevfb]

Actually, does this allow the fork repo to make use of the source repo's ANTHROPIC_API_KEY? That's probably not something most open source repos would want.

how so? could you please elaborate?

for the context: the PR is still opened in the source repo, just from the fork

here's a concrete example of the issue we're trying to fix here

[Tsuesun]

Actually, does this allow the fork repo to make use of the source repo's ANTHROPIC_API_KEY? That's probably not something most open source repos would want.

Not by default, you would need to enable it in the fork settings, My usage scenario is for only private repos and was thinking only of my personal use but, I do think it would be better to be explicit about this tbh when considering OSS projects.

I would imagine that OSS would need to have a similar set up to here were the CI doesn't run until a review is completed but that really needs to have some additional documentation to outline the risks.

[izaitsevfb]

@ashwin-ant, sorry for the direct ping again, but do you mind clarifying what you mean by:

this allow the fork repo to make use of the source repo's ANTHROPIC_API_KEY

I don't understand how this fix is related to the source repo's secret. Could you please describe the specific scenario you're concerned about, and, if possible, provide a direction on how we can address the existing bug with the constraints that you have in mind.

[seemethere]

Actually, does this allow the fork repo to make use of the source repo's ANTHROPIC_API_KEY? That's probably not something most open source repos would want.

No it should not have access to the API key since that's only a secret that would exist in the source repo.

The action also does not run in the forked repository so there's no way for the secret to actually be accessible.

[nbaju1]

Should the edge case described by @izaitsevfb with matching branch names perhaps be handled as well? I believe he has suggested solution for that here.

[strawgate]

We are also blocked by this and have resorted to maintaining a fork similar to pytorch

[ashwin-ant]

Can we run bun run format? Happy to merge after that

[Tsuesun]

Can we run bun run format? Happy to merge after that

Thanks @ashwin-ant, updated the PR