Repository navigation
[Bug]: Bare pull request numbers can't be linked on a self-hosted GitLab whose host name doesn't say "gitlab" #15390
Description
Activity
Note
Grok responding on behalf of Julius.
Triage
Thanks for the thorough report, @TonybynMp4. Your diagnosis matches what's on
mainat00eb8f6183.What's happening
The dialog never asks the server.
resolveLinkPullRequestInputbuilds the URL withchangeRequestUrlFor(identity.provider, ...), and that returns null forprovider: "unknown", which produces the error you saw.detectSourceControlProviderFromRemoteUrlonly marks a host as GitLab when it'sgitlab.comor has agitlabDNS label, socode.example.comstaysunknown.The Pull requests page already handles this case. It calls
resolveHandlewith a provider built from the remote URL, whose name is the real host, andrefineUnknownGitLabRemotematches that againstglab auth status. That result isn't written back onto the repository identity, though, so the dialog still seesunknown.The
refinecallback inRepositoryIdentityResolverLayerLivecan't record GitLab either:- It calls
resolveHandlewith{ kind: "unknown", name: "Unknown", baseUrl: "" }. GitLab refinement comparesglabhosts toprovider.name, so it looks for a host namedunknownand never matches. - It keeps the original identity unless the refined kind is
forgejo.
Likely fix area
- The narrowest option is to pass the existing refinement the remote's real host instead of the placeholder, and keep
provider: "gitlab"on the identity whenglabis signed in to that host. That's close to the approach you described, and it reuses the check that already runs for unknown hosts, so it starts no new processes. - Some things should probably stay as they are. Hostname-based detection can stay unchanged, unrecognized hosts shouldn't be assumed to be GitLab, and when
glabisn't signed in to the host, the dialog should keep refusing bare numbers. Pasting a full merge request URL should keep working. - A useful test would fail while the placeholder host or the Forgejo-only write is still in place, and pass once a host
glabis signed in to is stored asgitlab. - Other forges whose host names don't match their provider, such as a GitHub Enterprise host without
githubin the name, are a separate case.
A maintainer will decide on the fix direction.
- It calls
Before submitting
Area
apps/server
Steps to reproduce
originis on a self-hosted GitLab with a host name that doesn't contain "gitlab", such ashttps://code.example.com/group/project.git.glabin to that host withglab auth login --hostname code.example.com.#1. Plain1behaves the same.Expected behavior
The dialog resolves
#1tohttps://code.example.com/group/project/-/merge_requests/1and links it, the same as on gitlab.com.Actual behavior
The dialog says "Paste a full URL; this project's host has no known pull request URL." Pasting the full merge request URL works.
Impact
Minor bug or occasional failure
Version or commit
mainat 00eb8f6Environment
Linux, desktop and web.
glabis signed in to the self-hosted host.Logs or stack traces
None. The dialog rejects the input before anything reaches the server.
Cause
The client builds the merge request URL from the project's
repositoryIdentity.provider. That field stays"unknown"when the host name doesn't name a provider, so the client has no URL shape to use.The server already knows the answer. The Pull Requests page asks
ghandglabwhich one is signed in to the remote's host, and it lists this project's merge requests fine.The repository identity resolver has a
refinestep for the same job, inRepositoryIdentityResolverLayerLiveinapps/server/src/server.ts. It only ever records Forgejo. It also hands the CLIs a placeholder provider named "Unknown", and GitLab's refinement compares the hosts fromglab auth statusagainst that name. So GitLab can never match there.Workaround
Paste the full merge request URL.
Fix
I have a fix ready and can open a PR. It moves the
refinestep into its own module, passes the remote's real host to the CLIs, and recordsgitlabon the identity whenglabis signed in to that host. It doesn't start any new processes, since the same check already runs for every unknown host. Two tests cover it, and the first fails without the fix.