What
bin/fm-pr-merge.sh cannot pin the forge host for its GitHub reads and mutation. Fix 2 of fm-stale-base-check-before-merge set out to close that and could not: the spelling it used silently removed the repository binding instead of tightening it, so it has been reverted to upstream's two-part form and the underlying gap is filed here.
Why the obvious spelling does not work
gh-axi parses --repo itself and requires exactly owner/name. A three-part value yields undefined with no error, and the flag is then omitted from the underlying call entirely, so the repository resolves from GH_REPO or the working directory remote.
Reproduction, run from inside a clone of this repository:
$ gh-axi pr view 241 --repo github.com/octocat/Hello-World
pull_request:
number: 241
title: "fix(bin): harden guarded merge execution in fm-pr-merge"
state: open
$ gh-axi pr view 241 --repo octocat/Hello-World
error: Item #241 does not exist in this repository
code: NOT_FOUND
The first command names a repository that has nothing to do with this one and returns this repository's PR 241. The binding was dropped and the CWD remote answered. The second, correctly formed, errors as it should.
That makes the three-part form strictly worse than no change: a guarded merge would resolve its target repository from ambient context rather than from the identity the run validated.
Why it cannot be expressed through this flag at all
gh-axi pr merge --help lists its supported merge flags as --method, --merge, --squash, --rebase, --auto, --delete-branch, --body, --body-file and --subject. There is no --hostname and no --sha. So neither the host nor the head can be pinned through the arguments this wrapper accepts, and the host cannot be pinned by embedding it in --repo either.
Current state, which is consistent rather than correct
After the revert, the reads and the mutation all resolve the host from ambient context. That is the same behaviour as before the task and it is at least self-consistent: read and mutation agree about which host they mean. The gap is that neither is pinned, so an ambient GH_HOST moves both together.
What a fix would need
Either a gh-axi way to pin the host per call, or a documented environment assignment on each invocation, or a decision that the guarded merge path addresses GitHub through a different client for the mutation. All three are larger than the task that found this and none is attempted here.
Provenance
Found while re-expressing the four guarded-merge fixes onto the merge path rebuilt by upstream sync round 1. Worth noting for whoever picks this up: the broken three-part spelling was present in fork PR #241 at 16 of 17 checks green, and no test caught it, because the merge-target contract had no refusal test at all - every case exercised only the permit branch. Refusal tests were added alongside the revert.
What
bin/fm-pr-merge.shcannot pin the forge host for its GitHub reads and mutation. Fix 2 offm-stale-base-check-before-mergeset out to close that and could not: the spelling it used silently removed the repository binding instead of tightening it, so it has been reverted to upstream's two-part form and the underlying gap is filed here.Why the obvious spelling does not work
gh-axiparses--repoitself and requires exactlyowner/name. A three-part value yieldsundefinedwith no error, and the flag is then omitted from the underlying call entirely, so the repository resolves fromGH_REPOor the working directory remote.Reproduction, run from inside a clone of this repository:
The first command names a repository that has nothing to do with this one and returns this repository's PR 241. The binding was dropped and the CWD remote answered. The second, correctly formed, errors as it should.
That makes the three-part form strictly worse than no change: a guarded merge would resolve its target repository from ambient context rather than from the identity the run validated.
Why it cannot be expressed through this flag at all
gh-axi pr merge --helplists its supported merge flags as--method,--merge,--squash,--rebase,--auto,--delete-branch,--body,--body-fileand--subject. There is no--hostnameand no--sha. So neither the host nor the head can be pinned through the arguments this wrapper accepts, and the host cannot be pinned by embedding it in--repoeither.Current state, which is consistent rather than correct
After the revert, the reads and the mutation all resolve the host from ambient context. That is the same behaviour as before the task and it is at least self-consistent: read and mutation agree about which host they mean. The gap is that neither is pinned, so an ambient
GH_HOSTmoves both together.What a fix would need
Either a
gh-axiway to pin the host per call, or a documented environment assignment on each invocation, or a decision that the guarded merge path addresses GitHub through a different client for the mutation. All three are larger than the task that found this and none is attempted here.Provenance
Found while re-expressing the four guarded-merge fixes onto the merge path rebuilt by upstream sync round 1. Worth noting for whoever picks this up: the broken three-part spelling was present in fork PR #241 at 16 of 17 checks green, and no test caught it, because the merge-target contract had no refusal test at all - every case exercised only the permit branch. Refusal tests were added alongside the revert.