Describe the bug
When a type: gitlab dependency uses an ssh:// URL with a non-standard port (e.g. ssh://git@gitlab-ssh.example.com:2222/...), the git sparse-fetch path constructs a remote URL using HTTPS against the same hostname. For GitLab instances where the SSH host alias differs from the web endpoint, this causes the git transport to speak TLS to an SSH-only host, then silently fall back to the GitLab REST API (which also fails because it reuses the SSH port with HTTPS).
To Reproduce
- Host: self-hosted GitLab at
gitlab.example.com:443 (HTTPS web) with SSH-only alias at gitlab-ssh.example.com:2222
- apm.yml:
dependencies:
apm:
- git: ssh://git@gitlab-ssh.example.com:2222/owner/repo.git
path: agents/some-agent.agent.md
type: gitlab
- Run
apm install
Observed result
HTTPSConnectionPool(host='gitlab-ssh.example.com', port=2222):
Max retries exceeded with url: /api/v4/projects/owner%2Frepo/repository/files/...
(Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number')))
With APM_DEBUG=1:
[DEBUG] git sparse fetch: host=gitlab-ssh.example.com repo=owner/repo ref=main paths=1
[DEBUG] git transport unavailable for gitlab-ssh.example.com/owner/repo; falling back to GitLab REST API (GitFileTransportError)
strace confirms the sparse-fetch worktree used git remote add origin https://gitlab-ssh.example.com/... and invoked git-remote-https. The SSH URL and custom port were lost.
Expected behavior
The original SSH URL and port should be preserved for the git transport remote URL. A git ls-remote over the same ssh:// URL with port 2222 succeeds from the same environment.
Environment:
- OS: Linux (container)
- APM Version: 0.30.0
- GitLab: self-hosted at
gitlab.example.com with SSH alias gitlab-ssh.example.com:2222
Logs
strace output showing the rewritten remote URL:
execve("/usr/local/libexec/git-core/git-remote-https", [...], "origin", "https://gitlab-ssh.example.com/owner/repo.git")
Manual verification that sparse fetch works with the correct URL:
$ git -c init.defaultBranch=main init -q
$ git remote add origin ssh://git@gitlab-ssh.example.com:2222/owner/repo.git
$ git sparse-checkout init --no-cone
$ git sparse-checkout set agents/some-agent.agent.md
$ git fetch --filter=blob:none --depth=1 origin main # succeeds
$ git checkout -q FETCH_HEAD
$ ls agents/some-agent.agent.md # exists
Additional context
Workaround: switch the dependency to the HTTPS web URL and add a GitLab token:
- git: https://gitlab.example.com/owner/repo.git
path: agents/some-agent.agent.md
type: gitlab
This requires HTTPS credentials for the GitLab instance rather than SSH keys.
Describe the bug
When a
type: gitlabdependency uses anssh://URL with a non-standard port (e.g.ssh://git@gitlab-ssh.example.com:2222/...), the git sparse-fetch path constructs a remote URL using HTTPS against the same hostname. For GitLab instances where the SSH host alias differs from the web endpoint, this causes the git transport to speak TLS to an SSH-only host, then silently fall back to the GitLab REST API (which also fails because it reuses the SSH port with HTTPS).To Reproduce
gitlab.example.com:443(HTTPS web) with SSH-only alias atgitlab-ssh.example.com:2222apm installObserved result
With
APM_DEBUG=1:straceconfirms the sparse-fetch worktree usedgit remote add origin https://gitlab-ssh.example.com/...and invokedgit-remote-https. The SSH URL and custom port were lost.Expected behavior
The original SSH URL and port should be preserved for the git transport remote URL. A
git ls-remoteover the samessh://URL with port 2222 succeeds from the same environment.Environment:
gitlab.example.comwith SSH aliasgitlab-ssh.example.com:2222Logs
straceoutput showing the rewritten remote URL:Manual verification that sparse fetch works with the correct URL:
Additional context
Workaround: switch the dependency to the HTTPS web URL and add a GitLab token:
This requires HTTPS credentials for the GitLab instance rather than SSH keys.