fix(code-review): resolve PR base host-agnostically (GitHub Enterprise fork fix)#818
Open
davidalee wants to merge 2 commits into
Open
Conversation
Replace hard-coded `github.com:` / `github.com/` substring matching and `https://github.com/...` fallback URL with host+repo matching driven by values derived from the PR URL. On GitHub Enterprise (or any non- github.com host), the previous awk silently failed to identify the upstream remote in fork workflows and fell through to `origin` — which in fork setups points at the user's fork — producing the wrong merge base or no base. The agent now derives `<base-host>` and `<base-repo>` from the same PR URL it already parses, lowercases both for case-insensitive comparison, and the awk block extracts (host, owner/repo) from each remote URL generically — handling `https://[user@]host[:port]/owner/repo[.git]`, `ssh://[user@]host[:port]/owner/repo[.git]`, and scp-form `user@host:owner/repo[.git]`. Strips userinfo, port, and trailing `.git` before comparison. The HTTPS fallback URL also uses `<base-host>` instead of a hard-coded `github.com`. No behavior change for `github.com` users; enterprise hosts now resolve correctly in fork workflows.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3a32c49243
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
- keep URL-form remote host ports when resolving the PR base remote - allow scp-form SSH remotes to match a ported PR host without the web UI port - add executable regression coverage for HTTPS, ssh URL, and scp-form GHE remotes Note: pre-existing failure in bun test: tests/skills/ce-release-notes-helper.test.ts cannot start Bun.serve on port 0 (EADDRINUSE).
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
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.
Summary
The stable
ce-code-reviewskill silently picks the wrong merge base — or no base at all — on GitHub Enterprise or any non-github.comhost when the reviewer is working from a fork. The base-resolution awk block inSKILL.mdmatches remotes by literalgithub.com:/github.com/substring, and the HTTPS fallback URL is hard-coded tohttps://github.com/.... On GHE,PR_BASE_REMOTEends up empty, the script falls through toorigin, and in fork workflowsoriginis the user's fork — so the resulting diff is either empty, incorrect, or relative to the wrong base.This PR makes base resolution host-agnostic: the agent derives both
<base-host>and<base-repo>from the same PR URL it already parses, and the awk block extracts(host, owner/repo)from each remote URL generically. No behavior change forgithub.comusers.How this was uncovered
While building
ce-code-review-betain #784 (Codex CLI delegation), the Codex code-review bot flagged the identical hard-coding pattern in the beta variant'sresolve-base.sh:That feedback was resolved in #784. Auditing the stable skill on
mainconfirmed the same root cause — now living inline inSKILL.mdafter #815 replaced the standalone script with prose-driven base detection. This PR ports the fix.What changed
plugins/compound-engineering/skills/ce-code-review/SKILL.md— base-resolution prose and awk:<base-host>and<base-repo>from the PR URL (previously only the repo portion). Calls out case-insensitivity and shows a GHE example alongside the existinggithub.comexample.index($2, "github.com:<base-repo>") || index($2, "github.com/<base-repo>")substring checks with a per-remote parser that handles:https://[user@]host[:port]/owner/repo[.git]ssh://[user@]host[:port]/owner/repo[.git]user@host:owner/repo[.git].git; lowercases host and owner/repo before exact-equality comparison.https://github.com/<base-repo>.git→https://<base-host>/<base-repo>.git.Why this is safe to merge
github.com: the new awk produces the same remote pick for canonicalgithub.comURLs, verified across HTTPS, scp-form, mixed-case, userinfo, port, and.git/no-.gitvariants.org/repoPR does not spuriously match a remote atorg/repo-extra(exact equality, not substring).bun testsuite passes (1340/1340);bun run release:validateclean.Test plan
bun test— all 1340 tests pass on this branchbun run release:validate— metadata in syncgit@ghe.acme.com:EveryInc/compound-engineering-plugin.gitmatches(ghe.acme.com, everyinc/compound-engineering-plugin)✓https://x-token@ghe.acme.com/Org/Repo.gitmatches(ghe.acme.com, org/repo)✓git@github.com:org/repo-extra.gitdoes not match(github.com, org/repo)✓git@github.com:org/repo.gitstill matches(github.com, org/repo)✓ (regression guard)Related
resolve-base.shwith inline prose)