Skip to content

Fix GitLab fetch failing on GITLAB_HOST mismatch#215

Open
dhilgaertner wants to merge 1 commit intomainfrom
feature/crow-195-glab-host-mismatch
Open

Fix GitLab fetch failing on GITLAB_HOST mismatch#215
dhilgaertner wants to merge 1 commit intomainfrom
feature/crow-195-glab-host-mismatch

Conversation

@dhilgaertner
Copy link
Copy Markdown
Contributor

Summary

  • glab refused to run when Crow's inherited CWD was a git repo whose remote didn't match GITLAB_HOST, aborting IssueTracker.fetchGitLabIssues and three sibling glab calls.
  • Fix: add an optional cwd: parameter to the shell helpers in IssueTracker and ProviderManager, and invoke glab from NSHomeDirectory() so its auto-detection finds no conflicting remotes.

Test plan

  • make build (clean)
  • swift test for top-level (31/31 passing) and CrowProvider package (25/25 passing)
  • Manual: launch Crow with at least one GitLab workspace configured while the app's CWD is a GitHub-only repo; verify assigned GitLab issues now render in the sidebar and the fetchGitLabIssues(host:) failed: log line no longer appears.

Closes #195

🤖 Generated with Claude Code

glab refuses to start when invoked from a git repo whose remote doesn't
correspond to GITLAB_HOST ("None of the git remotes configured for this
repository correspond to the GITLAB_HOST environment variable"). The
Crow app's inherited CWD is typically a GitHub repo, so every glab call
aborted and the entire GitLab fetch failed — assigned GitLab issues
never rendered.

Add an optional `cwd:` parameter to the shell helpers in IssueTracker
and ProviderManager, and pass NSHomeDirectory() at the four glab call
sites (issue list, api reconcile, mr view, issue view). HOME is not a
git repo, so glab's auto-detection finds no conflicting remotes.

Closes #195

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@dhilgaertner dhilgaertner requested a review from dgershman as a code owner April 25, 2026 00:20
Copy link
Copy Markdown
Collaborator

@dgershman dgershman left a comment

Choose a reason for hiding this comment

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

Code & Security Review

Critical Issues

None.

Security Review

Strengths:

  • Uses NSHomeDirectory() as the working directory — a safe, predictable path that avoids information leakage from arbitrary git repos
  • No new environment variable handling or user input flows introduced
  • The cwd parameter is optional with a nil default, preserving backward compatibility for non-glab callers

Concerns:

  • None identified. The change is narrowly scoped to process working directory control.

Code Quality

  • The fix is consistent across both files: IssueTracker.swift (3 call sites + 2 shell helper signatures) and ProviderManager.swift (2 call sites + 1 shell helper signature)
  • All glab invocations now pass cwd: NSHomeDirectory() — no missed call sites
  • The cwd parameter placement (between env: and the variadic args) is clean and follows the existing parameter style
  • CrowProvider tests pass (25/25)
  • Pre-existing (not this PR): ProviderManager.shell calls waitUntilExit() before readDataToEndOfFile() (L137-138), which can deadlock if output exceeds the 64 KB pipe buffer. IssueTracker.shell already reads-then-waits (fixed in a prior PR). Worth a follow-up but not blocking.

Summary Table

Priority Issue
🟢 Green Pre-existing: ProviderManager.shell pipe read order (potential deadlock on large output) — follow-up item

Recommendation: Approve — clean, minimal fix that solves the GITLAB_HOST mismatch by running glab from HOME instead of the app's inherited CWD. No security concerns, consistent implementation, tests pass.

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.

GitLab issues not loading: glab fails on repos without matching GitLab remote

2 participants