Go get metadata incorrect for subgroups
I have a repository in a subgroup at https://gitlab.com/my-org/my-group/my-private-repo. I import that into my go project by running go get gitlab.com/my-org/my-group/my-private-repo.
The go toolchain resolves the import path to a repository by first sending a GET request to the most likely candidate, https://gitlab.com/my-org/my-group?go-get=1, before trying the more specific https://gitlab.com/my-org/my-group/my-private-repo?go-get=1. Note that the first request is to the subgroup and that these requests use an Authorization header with the Gitlab token, sourced from the .netrc file.
This is described in the go docs
When the go command downloads a module in direct mode, it first looks up the module server’s URL with an HTTP GET request based on the module path. It looks for a tag with the name go-import in the HTML response. The tag’s content must contain the repository root path, the version control system, and the URL, separated by spaces. See Finding a repository for a module path for details.
go get's behaviour can be reproduced with
curl -H "Authorization: Basic BASE64_AUTH_TOKEN" "https://gitlab.com/my-org/my-group?go-get=1"I would expect Gitlab to respond with a neutral or negative response as
- The go toolchain is trying to discover a repository for an import path, and the response should indicate that existence or fail
- The request is authenticated, so presumably there are no data leak issues
Instead, Gitlab responds as if the subgroup is a repository
<html><head><meta name="go-import" content="gitlab.com/my-org/my-group git https://gitlab.com/my-org/my-group.git"><meta name="go-source" content="gitlab.com/my-org/my-group https://gitlab.com/my-org/my-group https://gitlab.com/my-org/my-group/-/tree/master{/dir} https://gitlab.com/my-org/my-group/-/blob/master{/dir}/{file}#L{line}"></head><body>go get https://gitlab.com/my-org/my-group</body></html>%Gitlab's response provides the go toolchain an erroneous repo URL of https://gitlab.com/my-org/my-group.git which does not and has not ever existed.
This erroneous URL of course thoroughly confuses the go toolchain, which faithfully attempts to git clone the provided repo URL but immediately fails. And this failure means the go toolchain never gets the opportunity to try the full path.
Can you please change the behaviour so that a ?go-get=1 request never responds with a non-existent repository URL? Or at the very least, correct the behaviour for requests which are Authorized?