Skip to content

fix(github): support GitHub Enterprise for PR creation#1244

Merged
arnestrickmann merged 1 commit intogeneralaction:mainfrom
krzysztofcybulski:fix/ghe-pr-creation
Mar 3, 2026
Merged

fix(github): support GitHub Enterprise for PR creation#1244
arnestrickmann merged 1 commit intogeneralaction:mainfrom
krzysztofcybulski:fix/ghe-pr-creation

Conversation

@krzysztofcybulski
Copy link
Contributor

@krzysztofcybulski krzysztofcybulski commented Mar 3, 2026

Summary

PR creation was previously broken on GitHub Enterprise (GHE) instances because the codebase assumed all GitHub remotes were hosted on github.com. Specifically:

  • gh repo view --json nameWithOwner fails on GHE hosts if they are not the default, causing the --repo and --head owner:branch flags to be malformed or missing.
  • hasGitHubRemote() explicitly searched for the github.com string in remote URLs, which caused GHE repositories to be incorrectly identified as non-GitHub.

This PR removes these assumptions and allows the GitHub CLI (gh) to handle host resolution natively based on the local git configuration.

Changes

src/main/ipc/gitIpc.ts — PR creation (local and remote)

  • Removed --repo flag: Both local and remote PR creation paths previously attempted to resolve nameWithOwner via gh repo view to pass an explicit --repo owner/repo flag. This is unnecessary as gh pr create automatically infers the repository from the working directory's git remote. The explicit flag caused failures on GHE when the host was not github.com.
  • Simplified --head flag: Changed from owner:branch to using the branch name directly. The owner: prefix is only necessary for cross-fork PRs, which are not currently a use case for Emdash. This avoids a failure cascade when repository resolution fails.
  • Removed repo URL parsing fallback: Deleted the regex-based SSH/HTTPS remote URL parsing logic. This logic was fragile, did not support GHE URL patterns, and was only used to support the now-removed --repo flag.

src/main/services/GitHubService.ts — Issue listing

  • Removed hasGitHubRemote() method: This guard previously checked for github.com in the output of git remote -v before executing issue commands. On GHE repositories, this check always failed, silently disabling issue integration features.
  • Streamlined host validation: Removed the manual check in favor of the existing error handling in listIssues() and searchIssues(). On non-GitHub repositories, the gh CLI fails quickly; the code now catches these failures and returns an empty list as intended.

Test Plan

  • Type Check: Verified that pnpm run type-check passes.
  • Unit Tests: Verified that pnpm exec vitest run passes (noting that 3 pre-existing failures in TaskLifecycleService.test.ts are unrelated to these changes).
  • Manual (github.com): Confirmed PR creation still functions correctly for public GitHub repositories.
  • Manual (GHE): Confirmed PR creation now succeeds on GitHub Enterprise instances.
  • Manual (Non-GitHub): Confirmed that opening the issue selector on a non-GitHub repository returns an empty list without throwing UI errors.

@vercel
Copy link

vercel bot commented Mar 3, 2026

@krzysztofcybulski is attempting to deploy a commit to the General Action Team on Vercel.

A member of the Team first needs to authorize it.

@greptile-apps
Copy link
Contributor

greptile-apps bot commented Mar 3, 2026

Greptile Summary

This PR fixes GitHub Enterprise (GHE) support for PR creation by removing the --repo flag from gh pr create in both local and remote SSH paths, and replacing the hardcoded github.com string check in hasGitHubRemote() with a gh repo view call. The gitIpc.ts changes are well-reasoned and correct, but the GitHubService.ts change introduces two issues:

  • Performance regression: hasGitHubRemote() is now a network call (gh repo view) instead of a local git operation. Since it gates both listIssues() and searchIssues(), and searchIssues() is likely invoked on each search keystroke, every search now triggers two sequential API calls instead of one, doubling latency and API usage.
  • Semantic regression: The function now returns false when the user is offline or when gh is not authenticated — even for repositories that genuinely have GitHub remotes. This silently disables issue listing and PR status for valid GitHub repos in those scenarios, a regression not covered by the PR's test plan.

Confidence Score: 3/5

  • Safe to merge for the GHE PR creation fix in gitIpc.ts, but the GitHubService.ts change introduces performance and reliability regressions that should be addressed first.
  • The gitIpc.ts changes are clean and correct — removing --repo and simplifying --head are the right approach for GHE compatibility. However, the hasGitHubRemote() rewrite changes a fast local check into a network API call that is invoked on every issue search keystroke (doubling API calls) and introduces a regression where GitHub features are hidden when the user is offline or gh is unauthenticated.
  • src/main/services/GitHubService.ts — the hasGitHubRemote() implementation needs caching or a different approach to avoid the performance and offline regressions.

Important Files Changed

Filename Overview
src/main/services/GitHubService.ts hasGitHubRemote() replaced with a gh CLI network call, introducing a performance regression (doubles API calls per search keystroke) and semantic change (returns false when offline or gh is unauthenticated, hiding GitHub features for legitimate GitHub repos).
src/main/ipc/gitIpc.ts Removed --repo flag and owner:branch head format from both local and remote SSH gh pr create paths; changes are correct for same-repo worktrees and GHE support. The repoNameWithOwner resolution code (including its fallback URL parser) is cleanly removed.

Sequence Diagram

sequenceDiagram
    participant UI as UI (Search Input)
    participant GHS as GitHubService
    participant GH as gh CLI / GitHub API

    Note over UI,GH: Before this PR (local check only)
    UI->>GHS: searchIssues(projectPath, term)
    GHS->>GHS: git remote -v (local, instant)
    GHS->>GH: gh issue list --search ... (1 network call)
    GH-->>GHS: issues[]
    GHS-->>UI: results

    Note over UI,GH: After this PR (two network calls per keystroke)
    UI->>GHS: searchIssues(projectPath, term)
    GHS->>GH: gh repo view --json nameWithOwner (network call #1)
    GH-->>GHS: nameWithOwner or error
    GHS->>GH: gh issue list --search ... (network call #2)
    GH-->>GHS: issues[]
    GHS-->>UI: results

    Note over UI,GH: PR creation - GHE now works
    UI->>GHS: createPR(taskPath, ...)
    GHS->>GH: gh pr create --title ... --base ... --head branch
    GH-->>GHS: PR URL
    GHS-->>UI: success
Loading

Last reviewed commit: 9aeeac0

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 files reviewed, 2 comments

Edit Code Review Agent Settings | Greptile

Remove --repo flag from gh pr create and let gh auto-detect the correct
host from the git remote. Previously the --repo owner/repo flag caused
gh to default to github.com, breaking PR creation on GHE instances.

Also replace the hardcoded github.com check in hasGitHubRemote() with
gh repo view, which works for any authenticated GitHub instance.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@arnestrickmann
Copy link
Contributor

Thanks for the PR! GHE support is a real gap we've been missing. @krzysztofcybulski

@arnestrickmann arnestrickmann merged commit 17ab44b into generalaction:main Mar 3, 2026
2 of 3 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.

2 participants