Go meta tag prevents usage of ssh
Summary
Go has a feature where the importpath can be set by the remote server. See this doc https://golang.org/cmd/go/#hdr-Remote_import_paths. The public GitLab server hosted at gitlab.com responds with a meta tag similar to <html><head><meta name="go-import" content="gitlab.com/Pixdigit/turboOcto git https://gitlab.com/Pixdigit/turboOcto.git" /></head></html>
As you might see it indicates the RepoPath at https://[…]
. This is problematic if the git remote url is set to ssh://[…]
. The go toolchain now refuses to use that url since it does not match the url indicated by the meta tag.
Steps to reproduce
- Install go at its latest version from golang.org and configure it in a default environment.
- Create new repo at gitlab.com.
-
go get
the new repo via the go import path. -
git remote set-url git@gitlab.com:[…]
to the appropriate url. -
go get -u
should now throw the described error
Example Project
As seen above: https://gitlab.com/Pixdigit/turboOcto
What is the current bug behavior?
ssh urls are unusable for go
repositories
What is the expected correct behavior?
Good question. I don't suppose GitLab can determine when ssh is required and when https. Easiest way would be an option in settings whether to respond with an https or ssh link.
Relevant logs and/or screenshots
package gitlab.com/Pixdigit/turboOcto: gitlab.com/Pixdigit/turboOcto is a custom import path for https://gitlab.com/Pixdigit/turboOcto.git, but /home/max/go/src/gitlab.com/Pixdigit/turboOcto is checked out from git+ssh://git@gitlab.com/Pixdigit/turboOcto.git
<html><head><meta name="go-import" content="gitlab.com/Pixdigit/turboOcto git https://gitlab.com/Pixdigit/turboOcto.git" /></head></html>%
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Expand for output related to GitLab environment info
This bug happens on GitLab.com
Results of GitLab application Check
Expand for output related to the GitLab application check
This bug happens on GitLab.com
Possible fixes
I have no idea about the inner workings of the GitLab infrastructure
Workaround
A workaround is possible though using a https for each repo but all local repos have to be reconfigured and for each write operation on the remote repo username and password have to be supplied. For a hobby project such as mine this is acceptable but makes it especially difficult for teams who push more than once a day.
I dont know the pace with which you develop so I didn't give a version to which this feature is expected. However since I imagine the workload not to be big I think it could be done relatively quick.
((Edit: Just noticed the labels are gone. Maybe I just forgot but if someone removed them on purpose please leave a notice.))
/label ~bug ~S3 ~P3