$ curl -sSL https://honnef.co/go/tools/cmd/staticcheck?go-get=1
<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx/1.12.1</center>
</body>
</html>
bufdev
All 25 comments
Running on travis:
$ go get -u honnef.co/go/tools/cmd/megacheck
package honnef.co/go/tools/cmd/megacheck: unrecognized import path "honnef.co/go/tools/cmd/megacheck" (parse https://honnef.co/go/tools/cmd/megacheck?go-get=1: no go-import meta tags ())
kozlovic
on 28 Feb 2018
It's fixed now. Sorry for the inconvenience.
dominikh
on 28 Feb 2018
Thanks!
kozlovic
on 28 Feb 2018
I recently had to remove staticcheck from our build because of honnef.co going down. This is also the second time in recent history it has gone down. Is there a more stable way to consume gotools than through honnef.co?
robbert229
on 28 Feb 2018
in 2017, honnef.co/go had approximately 6 hours of downtime, so about a 99.9% uptime. That's higher than what GitHub managed to achieve in 2017. Of course, honnef.co/go/ still depends on GitHub for the actual git clone, which reduces the overall uptime. However, honnef.co/go isn't being the bottleneck here.
Of course, that doesn't really matter, because: you should be aiming for reproducible and reliable builds. Part of that means not depending on external factors. You should be vendoring (or caching, or internally mirroring) your dependencies and tools. Even if neither GitHub nor honnef.co ever went down, the data served could still be broken in various ways, such as a buggy commit on the master branch.
I may, however, consider releasing pre-built binaries on GitHub soon, if there is interest in that.
dominikh
on 28 Feb 2018
@dominikh First thank you for your work.. let's not forget that you are doing this on your free time...
I thought about vendoring, but you do some updates quite frequently (adding new checks, etc..) and the nice thing about doing the got get -u in travis is that it would always run with the latest checks that you have included. That being said, I could vendor and update from time to time. Things to think about.. Again, thanks for your work!
kozlovic
on 28 Feb 2018
@dominkh BTW don't take my comment as ungratefulness. I really appreciate the wonderful tools you have written that add significant value and catch defects before they leave the door.
robbert229
on 1 Mar 2018
I’d be highly in favor of pre-built binaries. I’m happy to write a script
that does this for you for the main os/arch pairs.
On Thu, Mar 1, 2018 at 1:07 AM John Rowley notifications@github.com wrote:
@dominkh BTW don't take my comment as ungratefulness. I really appreciate
the wonderful tools you have written that add significant value and catch
defects before they leave the door.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dominikh/go-tools/issues/269#issuecomment-369427858,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AECGvHiK3wEpxtaNF98l-40XG_GZ8Yrtks5tZzvBgaJpZM4SXB3A
.
bufdev
on 1 Mar 2018
Thank you for the offer, Peter, but I'll be able to write it myself :)
I've filed https://github.com/dominikh/go-tools/issues/271 to track the progress on it.
dominikh
on 1 Mar 2018
@dominikh this seems to be an issue again right now?
rajveerappan
on 1 Aug 2018
Have you though about switching the import path to your github, from honnef.co. Even if it technically has less downtime than github, most workflows stop when github is down, travis builds stop, even some of your tools have github.com imports. It's also a additional opaque attack vector.
With all that being said, these tools are epic. Thank you so much for you're work on them!
barshow
on 1 Aug 2018
I'm glad you guys added new comments to this, I was just going down the rabbit hole trying to figure out why one of my base Docker images was beginning to fail building. Strongly considering pulling the repo from a previous successful image, pushing it to my own "fork" repo, and calling it done.
potto007
on 1 Aug 2018
Same here :(
glerchundi
on 1 Aug 2018
Have you though about switching the import path to your github, from honnef.co
Only if you consider vendoring your dependencies so issues like these don't impact you ;-)
At any rate, the issue should be fixed now.
Pre-built binaries will land with the next version of staticcheck, which should be in time for Go 1.11.
dominikh
on 1 Aug 2018
Wouldn't you know... right as I finish extracting the files from my previous build images, and refactoring my build, the thing came back up. ;)
potto007
on 1 Aug 2018
Vendoring is an acceptable strategy, but if you happen to need to be upgrading some other dependency while any one of the tens of vanity sources are down then tools like dep cannot run.
We've vendored our dependencies to help alleviate these problems, and it has, but it's important to acknowledge that this is not a perfect solution. We are looking forward to when vgo comes out so we can have just one point of failure in these situations.
cameracker
on 1 Aug 2018
Vendoring is an acceptable strategy, but if you happen to need to be upgrading some other dependency while any one of the tens of vanity sources are down then tools like dep cannot run.
That sounds like a serious flaw in dep. None of your dependencies should depend on staticcheck, so updating any of those dependencies shouldn't fail because staticcheck fails to update. Updating a dependency shouldn't even attempt to update unrelated packages.
We are looking forward to when vgo comes out so we can have just one point of failure in these situations.
Ah yes, the coveted SPOF
dominikh
on 1 Aug 2018
It's better than 2 SPOFs ;)
cameracker
on 1 Aug 2018
@dominikh vendoring makes sense for application code dependencies. And can break depending on how you structure you tests. Is there a reason not to host from github?
barshow
on 1 Aug 2018
Is there a reason not to host from github?
The major reason for using vanity imports is being able to migrate away from a hosting platform without having to change import paths. C.f. the shutdown of code.google.com.
The major reason for not changing from the current import path to anything else is the large amount of people using the current import paths.
dominikh
on 1 Aug 2018
@dominikh Has this happened again? I'm getting unrecognized import path \"honnef.co/go/tools\" (https fetch: Get https://honnef.co/go/tools?go-get=1: x509: certificate is valid for *.netlify.com, netlify.com, not honnef.co) when using cloud.google.com/go/pubsub.
matryer
on 19 Nov 2019
@dominikh - I guess it is down again. Getting unrecognized import path "honnef.co/go/tools" on my builds.
dmrajkarthick
on 19 Nov 2019
Same
unrecognized import path "honnef.co/go/tools" (parse https://honnef.co/go/tools?go-get=1: no go-import meta tags ())
Imelstorm
on 19 Nov 2019
go: honnef.co/go/[email protected]: unrecognized import path "honnef.co/go/tools" (parse https://honnef.co/go/tools?go-get=1: no go-import meta tags ())
mFarghaly
on 19 Nov 2019
Please see https://github.com/dominikh/go-tools/issues/658#issuecomment-555551344
dominikh
on 19 Nov 2019
Related issues
igungor
·
3Comments
tamird
·
3Comments
ryboe
·
3Comments
jtreleaven
·
3Comments
dominikh
·
4Comments
Most helpful comment
The major reason for using vanity imports is being able to migrate away from a hosting platform without having to change import paths. C.f. the shutdown of code.google.com.
The major reason for not changing from the current import path to anything else is the large amount of people using the current import paths.