GitLab CLI Bug: Host Mismatch in Repository Resolution Causes 404 Errors

GitLab CLI Bug: Host Mismatch in Repository Resolution Causes 404 Errors

Issue Description

Critical Bug: The glab CLI commands fail with "404 Not Found" on the first run when using SSH Git remotes that point to different hosts than the API endpoints, but work correctly on subsequent runs. This affects ALL glab commands that use repository resolution, not just CI commands.

Steps to Reproduce

1. Setup Environment:

   # Clone a repository with SSH remote pointing to different host than API
   git clone git@git.example.com:owner/repo.git
   cd repo
   
   # Configure glab with different hosts
   glab auth login --hostname git.example.com --api-host api.example.com

2. First Run (Fails):

   # Any of these commands will fail on first run
   glab ci list
   glab issue list
   glab mr list
   glab project view
   # ERROR: 404 Not Found

3. Second Run (Works):

   # Same commands work on subsequent runs
   glab ci list
   # Shows results successfully

Expected Behavior

All glab commands should work consistently on both first and subsequent runs, using the correct host for repository operations.

Actual Behavior

• First Run: Fails with 404 Not Found for any command
• Subsequent Runs: Works correctly for all commands

Root Cause Analysis

Primary Issue

During initial cache creation, the repository resolution algorithm uses the host from the HTTP URL (api.example.com) instead of the Git remote host (git.example.com).

Affected Commands

This bug affects dozens of glab commands across all categories:

CI/CD Commands

• glab ci list, glab ci run, glab ci get, glab ci delete, glab ci status, glab ci trace, glab ci trigger, glab ci retry, glab ci cancel, glab ci artifact

Issue Commands

• glab issue create, glab issue delete, glab issue update, glab issue board create, glab issue board view

Merge Request Commands

• glab mr create, glab mr view, glab mr for, glab mr subscribe, glab mr unsubscribe, glab mr delete, glab mr update

Project Management Commands

• glab project archive, glab project transfer, glab label create, glab label delete, glab deploy-key list, glab deploy-key get, glab deploy-key delete

Other Commands

• glab schedule create, glab schedule list, glab schedule update, glab securefile download, glab securefile list, glab securefile get, glab changelog generate, glab stack sync, glab cluster agent bootstrap

Algorithm Behavior

1. First Run (No Cache):

   • Queries API and gets wrong host (api.example.com)
   • Caches resolution (repository path only, no host)
   • Fails with 404

2. Subsequent Runs (With Cache):

   • Uses cached resolution (repository path only, no host)
   • Correctly calls remote.RepoHost() which returns git.example.com
   • Works correctly

Code Location

The bug is in internal/glrepo/resolver.go in both BaseRepo and HeadRepo functions:

BaseRepo (lines 170-180):

selectedRepoInfo, _ := FromFullName(selectedRepo.HTTPURLToRepo, r.defaultHostname)
// ... later ...
return selectedRepoInfo, err  // Uses API host, not git remote host

HeadRepo (lines 275-276):

selectedRepoInfo, _ := FromFullName(selectedRepo.HTTPURLToRepo, r.defaultHostname)
// ... later ...
return selectedRepoInfo, err  // Same bug!

Impact

• User Experience: Inconsistent behavior (first run fails, subsequent runs work)
• Affected Users: Users with SSH Git remotes pointing to different hosts than API endpoints
• Common Scenario: Enterprise GitLab instances with separate SSH and HTTP hosts
• Scope: ALL glab commands that use repository resolution

Proposed Solution

Modify both BaseRepo and HeadRepo algorithms to use the Git remote host instead of the API host:

// Create the final repo object using the remote's host, not the API host
finalRepo := NewWithHost(selectedRepoInfo.RepoOwner(), selectedRepoInfo.RepoName(), remote.RepoHost())
return finalRepo, err

Environment

• glab version: v1.65.0
• OS: macOS (darwin, arm64)
• Git remote: SSH URL pointing to different host than API
• API endpoint: Different host than Git remote

Additional Context

This issue affects users in enterprise environments where:

• Git operations use SSH URLs (e.g., git@git.example.com:owner/repo.git)
• API operations use HTTP URLs (e.g., https://api.example.com/api/v4/)
• The hosts are different (git.example.com vs api.example.com)

The algorithm has built-in recovery for subsequent runs, but the initial failure creates a poor user experience and confusion across all glab commands.

Related Issues

None found - this appears to be a new issue.

Labels

• bug
• glrepo
• repository-resolution
• host-mismatch
• critical