Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: "unknown revision" error is misleading if the entire repo can't be found #47028

Open
sccr13plyr opened this issue Jul 2, 2021 · 3 comments
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@sccr13plyr
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.16.5 windows/amd64

What version of Git are you using (git version)?

$ git version
git version 2.31.1.windows.1

What version of GitLab are you using (Help)?

Private Instance of:

GitLab Enterprise Edition 12.9.2-ee

Does this issue reproduce with the latest release?

Yes. Also, in version 1.16.3.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\me\AppData\Local\go-build
set GOENV=C:\Users\me\AppData\Roaming\go\env
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\me\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\me\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.16.5
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\dev\electronGUI\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\me\AppData\Local\Temp\go-build3510898554=/tmp/go-build -gno-record-gcc-switches

What did you do (with results)?

There is an application that was developed and built on a Linux server. We wanted to build natively on Windows.

C:\dev> git clone https://gitlab.mydomain.com/group/subgroup/repo.git
...
C:\dev> cd repo

C:\dev\repo> go build
go: gitlab.mydomain.com/group/subgroup/dependency@v1.0.4: reading gitlab.mydomain.com/group/subgroup/dependency/dependency/go.mod at revision dependency/v1.0.4: unknown revision dependency/v1.0.4

C:\dev\repo> go mod tidy
go: gitlab.mydomain.com/group/subgroup/dependency@v1.0.4: reading gitlab.mydomain.com/group/subgroup/dependency/dependency/go.mod at revision dependency/v1.0.4: unknown revision dependency/v1.0.4

What did you expect to see?

When I perform the same actions on Linux (and I delete the go/pkg directory first), I would expect to see:
go: downloading gitlab.mydomain.com/group/subgroup/dependency v1.0.4
...

Further research...

I deleted the go.mod and go.sum files. I performed a go mod init and then a go mod tidy.

C:\dev\repo> go mod tidy
go: finding module for package gitlab.mydomain.com/group/subgroup/dependency/package
repo imports
        gitlab.mydomain.com/group/subgroup/dependency/package: module gitlab.mydomain.com/group/subgroup/dependency/package: git ls-remote -q origin in C:\Users\me\go\pkg\mod\cache\vcs\54e9acdb53cfeb2d47fd466e4c76c70590c3584874e86efb8a97d80c53287648: exit status 128:
        remote: The project you were looking for could not be found.
        fatal: repository 'https://gitlab.mydomain.com/group/subgroup.git/' not found

It appears as if Go is requesting the subgroup as a repository?! That is not correct. I am sure there is an underlying reason for this behavior, but it leaves users unclear about root cause.

I performed a git clone https://gitlab.mydomain.com/group/subgroup/dependency.git successfully. So, a direct git clone command was successful. As I had setup a credential helper, this was even non-interactive. It left me unsure about root cause, appearing that access was not an issue.

I did some online research and found #34094. This seemed relevant but did not provide immediate clarity for resolving the issue. There was some mention about non-support for interactive logins. There was also mention about private repositories, which is how dependency.git was setup.

Finally, I found #24606 go get on Windows. By setting up the _netrc in my User directory, I was able to resolve the issue.

If I am understanding the Go behaviour properly, it appears as if Go is accessing GitLab directly without Git (as git is setup with a credential helper) and having an access issue. However, it is not displaying any message indicating an access issue. It would be nice to have a message that displays some sort of access failure instead of this fallback that attempts to git a non-existent repository.

@dmitshur dmitshur changed the title Go - Git - GitLab on Windows - go build/mod tidy Package Retrieval Failure - Root Cause Not Clear from Output cmd/go: fails to download module from a private instance of GitLab on Windows, root cause not clear from output Jul 2, 2021
@dmitshur
Copy link
Contributor

dmitshur commented Jul 2, 2021

Thanks for the report. This may be due to a misconfiguration of the go command, or it could be a bug.

Are you familiar with documentation on private modules? See https://golang.org/cmd/go/#hdr-Configuration_for_downloading_non_public_code and https://golang.org/ref/mod#private-modules for a high level overview, and https://golang.org/ref/mod#private-module-proxy-direct more specifically (which applies if you're not using a private proxy). If not, can you read over it and see if there's something documented there that you're not taking account? Thanks.

CC @bcmills, @matloob.

@dmitshur dmitshur added GoCommand cmd/go modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Jul 2, 2021
@dmitshur dmitshur added this to the Backlog milestone Jul 2, 2021
@seankhliao
Copy link
Member

I believe this is an issue with gitlab where they will return a HTTP 200 + the go-import meta tag for any /a/b regardless the existence of the repo/group in order to not leak information. From the POV of the go command there's no information to indicate that b is not actually a repo until it tries to clone it.

Eg, https://gitlab.com/testgroup-395/subgroup-a/bar is a private repo under a subgroup

$ curl -Lv "https://gitlab.com/testgroup-395/subgroup-a/bar?go-get=1"
...
< HTTP/2 200
...
<html><head><meta name="go-import" content="gitlab.com/testgroup-395/subgroup-a git https://gitlab.com/testgroup-395/subgroup-a.git" /><meta name="go-source" content="gitlab.com/testgroup-395/subgroup-a https://gitlab.com/testgroup-395/subgroup-a https://gitlab.com/testgroup-395/subgroup-a/-/tree/master{/dir} https://gitlab.com/testgroup-395/subgroup-a/-/blob/master{/dir}/{file}#L{line}" /></head><body>go get https://gitlab.com/testgroup-395/subgroup-a</body></html>  

@sccr13plyr
Copy link
Author

Thanks for the report. This may be due to a misconfiguration of the go command, or it could be a bug.

Are you familiar with documentation on private modules? See https://golang.org/cmd/go/#hdr-Configuration_for_downloading_non_public_code and https://golang.org/ref/mod#private-modules for a high level overview, and https://golang.org/ref/mod#private-module-proxy-direct more specifically (which applies if you're not using a private proxy). If not, can you read over it and see if there's something documented there that you're not taking account? Thanks.

CC @bcmills, @matloob.

I have read the document you provided. It did cover the missing configuration I already added.

As noted at the bottom of the report, I did resolve the issue to get the module. It was a missing configuration (_netrc) that was setup on the Linux server (normal development platform), but was missed on my Windows PC (new development platform).

However, the error message was not clear as to the root cause. The root cause was an authorization failure. I do not know if the detection of this error is an issue with the GitLab service or Go's use of the service.

@bcmills bcmills changed the title cmd/go: fails to download module from a private instance of GitLab on Windows, root cause not clear from output cmd/go: "unknown revision" error is misleading if the entire repo can't be found Aug 10, 2021
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 10, 2021
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand cmd/go modules NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants