CODEWITHSUNDEEP
gogo-modules
Corey Ogburn
Corey Ogburn

Reputation: 24717

go get is adding folders when attempting to import?

We have 2 repos relevant to this question:

gitlab.com/company/product/team/service
gitlab.com/company/product/team/api

They both have go.mod files. The api repo is dead simple. It contains a dozen or so typescript files that go through a process to generate mirror image Go structs. We use these in integration and unit tests sort of like a stylesheet so we can test the structure of responses from service. Api has 0 imports. No fmt, time, nothing. Here's api's go.mod file:

module gitlab.com/company/product/team/api/v2

go 1.16

The latest tag on its master branch is v2.68.0. Service's go.mod has this require line for api:

require (
  ...
  gitlab.com/company/product/team/api/v2 v2.68.0
  ...
)

And it Works on My Machine(TM). When I run go get, go mod tidy, go mod download, go mod vendor, etc, the correct version gets downloaded. Not so in docker. To work with our CI/CD pipeline and eventually get deployed in k8, we build a docker image to house the code. The RUN go mod vendor in service's Dockerfile is giving us an error when it tries to import the api (adding a verbose flag does not result in more details here):

go: gitlab.com/company/product/team/api/[email protected]: reading gitlab.com/company/product/team/api/team/api/go.mod at revision team/api/v2.68.0: unknown revision team/api/v2.68.0

Note the repeated folders in the ../team/api/team/api/go.mod url.

Our Dockerfile is loaded with an SSH key that's registered with gitlab, the necessary entries into ~/.ssh/known_hosts are present, there's a ~/.netrc file with a gitlab access token that has the read_api permission, GOPRIVATE=gitlab.com/company/*, GO111MODULE=on, and when it runs go mod vendor it doesn't have issues with any of the rest of our gitlab.com/company/product/team/* imports. These mirror my local machine where go get works.

Why, for this one repo, would go mod vendor decide to repeat folders when attempting to import?

Upvotes: 1

Views: 100

Answers (1)

Corey Ogburn
Corey Ogburn

Reputation: 24717

Turns out the answer isn't anything that SO users would have had much insight into. The .netrc token we have in service's Dockerfile is an access token that only works in the service project. It was created by opening the settings of the service repo and creating the access token there instead of using a service account that has access to all the necessary repos. When go uses it to access the api it no longer grants access and go has issues asking gitlab which folder in the URL is the RepoRoot because gitlab erroneously claims all folders in the path are a repo. If you're using subgroups in gitlab and running go get, you know what I'm talking about.

It worked on my machine because my .netrc has my token and I have enough access to not be an issue.

We fixed it by updating the .netrc file in the dockerfile to use a token generated by a service account that has api access to all relevant repos.

I was about to delete the question, but finding resources talking about this problem are few and far between.

Upvotes: 1

Related Questions