Where did golint go?
Closed this issue · 24 comments
$ go get -u golang.org/x/lint/golint
package golang.org/x/lint/golint: unrecognized import path "golang.org/x/lint/golint" (parse https://golang.org/x/lint/golint?go-get=1: no go-import meta tags ())
Seeing this locally and from our ci server.
With additional verbosity:
go get -v -u golang.org/x/lint/golint
Fetching https://golang.org/x/lint/golint?go-get=1
Parsing meta tags from https://golang.org/x/lint/golint?go-get=1 (status code 404)
package golang.org/x/lint/golint: unrecognized import path "golang.org/x/lint/golint" (parse https://golang.org/x/lint/golint?go-get=1: no go-import meta tags ())
I believe it's related to https://golang.org/x/lint/golint returning 404 at the moment.
I was able to work around this issue by cloning the repository manually:
mkdir -p $GOPATH/src/golang.org/x \
&& git clone https://github.com/golang/lint.git $GOPATH/src/golang.org/x/lint \
&& go get -u golang.org/x/lint/golint
Consider adding --depth 1 on that git clone command, too. Shallow clone is sufficient to get around the issue
Conspiracy?
It is a huge blocker for all our CI again. Now I'll need to maintain a docker image just for this... once I can hit golint repo again
Golang's leftpad moment
twitch.tv/retool Lets you vendor your tools. It saved us today.
Dep lets you vendor your tools too.
I was going to point out github.com/roboll/go-vendorinstall as an alternative to twitch.tv/retool but now I'm intrigued that @johanbrandhorst said that dep can do this. Anyone want to share a recipe?
required = [
"golang.org/x/lint/golint",
]The original lint & vgo redirects were accidentally deployed from the master branch. They were never cherry-picked to the release branch. When golang.org was redeployed later from the release branch (correctly), it effectively reverted the lint redirects.
https://golang.org/cl/109095 does the necessary cherry-pick to the release branch.
I apologize for this. It was 100% my fault. Deploying the fix now.
Fix deployed.
No worries. It was a good reminder for us to not rely on external resources in CI builds. Thanks for the quick fix!
Here's what happened:
When deploying golang.org, our deploy script was (incorrectly) using the master branch of the x/tools repo instead of the proper release branch (release-branch.go1.10 in this case). We should not be deploying using the master branch because it causes issues like golang/go#25022, so I fixed it to use the proper branch and redeployed golang.org.
However, the change that added the x/vgo and x/lint redirects was never cherry-picked to release-branch.go1.10. Since we didn't have proper monitoring setup for these redirect URLs, we heard about it from the community instead (not the best way to hear about these issues).
First step will be to set up monitoring for all x/* redirects so that we are properly alerted if this happens again in the future.
I apologize again and truly appreciate everyone's patience on this.
Thank you for fixing this quickly and for the explanation of how it happened.
I'm glad to hear that not just one, but two problems are resolved as a result of this, and so Go is in a better shape now than before!
why not just use a container with all tools installed to build your project?
Dep lets you vendor your tools too.
@johanbrandhorst Can you provide more details on this? I'd be interested in dep cloning my system tools to a place other than current directory vendor.
I didn't fully understand the thread. This issue is closed. Is the "solution" to do a manual git clone now? Is there no more go get for this dependency?