Gitea: Support SSH for go get

Created on 8 Jul 2020 · 8Comments · Source: go-gitea/gitea

Gitea version (or commit ref): 1.12.1 built with GNU Make 4.2.1, go1.14.4 : bindata, sqlite, sqlite_unlock_notify
Git version: 2.24.3
Operating system: Arch Linux
Database (use [x]):
- [ ] PostgreSQL
- [ ] MySQL
- [ ] MSSQL
- [x] SQLite
Can you reproduce the bug at https://try.gitea.io:
- [ ] Yes (provide example URL)
- [ ] No
- [x] Not relevant
Log gist:

Description

We have a private gitea repository containing a go module. When we want to go get git.company.com/organization/private, gitea returns only the HTTPS link of the repository, not the SSH one.
To reproduce, one can simply open a link in the browser: https://git.company.com/organization/private?go-get=1
and examine the returned HTML:

<!DOCTYPE html>
<html>
<head>
<meta name="go-import" content="git.company.com/organization/private git https://git.company.com/organization/private.git">
<meta name="go-source" content="git.company.com/organization/private _ https://git.company.com/organization/private/src/branch/master{/dir} https://git.company.com/organization/private/src/branch/master{/dir}/{file}#L{line}">
</head>
<body cz-shortcut-listen="true">
go get git.company.com/organization/private
</body>
</html>

Here are the relevant source code locations:

templates/base/head.tmpl:   <meta name="go-import" content="{{.GoGetImport}} git {{.CloneLink.HTTPS}}">
modules/context/repo.go:    ctx.PlainText(200, []byte(com.Expand(`<meta name="go-import" content="{GoGetImport} git {CloneLink}">`,
modules/context/context.go:     <meta name="go-import" content="{GoGetImport} git {CloneLink}">

One can see in these files/lines that only the HTTPS path is ever returned. We expected that this can be at least configured to either return the SSH or HTTPS one. When disabling HTTPS for the repo, the returned links still stayed the same.

kinenhancement revieweconfirmed

Source

skaldesh

👍1

Most helpful comment

It does. We use it in production. The meta tag should look as following:

<meta name="go-import" content="git.company.com/organization/private git ssh://[email protected]/organization/private">

When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries https://, then git+ssh://.

https://golang.org/cmd/go/#hdr-Remote_import_paths

r0l1 on 9 Jul 2020

👍3

All 8 comments

I don't think go get support SSH protocol.

lunny on 9 Jul 2020

It does. We use it in production. The meta tag should look as following:

<meta name="go-import" content="git.company.com/organization/private git ssh://[email protected]/organization/private">

When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries https://, then git+ssh://.

https://golang.org/cmd/go/#hdr-Remote_import_paths

r0l1 on 9 Jul 2020

👍3

It does. We use it in production. The meta tag should look as following:
<meta name="go-import" content="git.company.com/organization/private git ssh://[email protected]/organization/private">
When a version control system supports multiple protocols, each is tried in turn when downloading. For example, a Git download tries https://, then git+ssh://.

https://golang.org/cmd/go/#hdr-Remote_import_paths

Interesting! Thanks for the information.

lunny on 9 Jul 2020

It's quite useful for private internal git modules :)

r0l1 on 9 Jul 2020

OK looking at: https://github.com/golang/go/blob/95e1ea4598175a3461f40d00ce47a51e5fa6e5ea/src/cmd/go/internal/get/discovery.go#L36-L64

I think we could even have a second go-import tag which would save yet another setting...

zeripath on 11 Jul 2020

Actually looking on - I think that might not work:

https://github.com/golang/go/blob/8cb865c9197f0f383b0bde48e37faea7b7a2451d/src/cmd/go/internal/get/vcs.go#L815

https://github.com/golang/go/blob/8cb865c9197f0f383b0bde48e37faea7b7a2451d/src/cmd/go/internal/get/vcs.go#L979-982

Sigh.

zeripath on 11 Jul 2020

OK I think this is going to need (yet) another setting. The ideal would be a global setting and a per repository setting.

Simply because every time we do this we're causing a change of schema - I think we need a generic settings system and I'm opening an issue for that.

zeripath on 12 Jul 2020

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.