Add tools as go modules

[jukie]

What this PR does / why we need it:
Follows go best practices. Imports tool dependencies as go modules instead of with "go get"

Which issue(s) this PR fixes:
Fixes #918

[k8s-ci-robot]

Welcome @jukie!

It looks like this is your first PR to kubernetes/kube-state-metrics 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/kube-state-metrics has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[jukie]

/assign @tariq1890

[brancz]

I have seen this practice lately, but I'm unsure how I feel about it. What benefits does this actually have?

[jukie]

One thing I see is that it pins module versions between different machines so it removes another avenue of the “works on my machine” issue.

[jukie]

I’m still new at this but it might also help keep your build cleaner according to this - https://stackoverflow.com/questions/56842385/using-go-get-to-download-binaries-without-adding-them-to-go-mod/57313319#57313319

[brancz]

hmm .. especially with #903, we just introduced two more rather large tools, I'm not sure that's something that I always want to have checked into the repo. Wdyt @tariq1890 @lilic ?

[jukie]

It's a separate package so it wouldn't be included in the builds if that's one of the concerns, but if you're checking out the repo isn't it also expected that you'd want to include the build tools? I'm trying to understand what the negatives would be. Doesn't the current local workflow include a go get X (or via the Makefile)?

[brancz]

We check in the vendor directory which is what concerns me in terms of checking in the dependency code as well blowing up the repo size.

[jukie]

This is highly debated topic (golang/go#25922) but where else should those dependencies be stored? It's certainly not my call, so I can make whatever changes you'd like.
I imagine a user would be running go get on the build tools after checkout anyways, is that correct?

[tariq1890]

@brancz I am in favour of tracking tool dependencies this way since we also have better control over which version we'd like to import. Since it's a recommended practice by the Go team, we can follow this.

We can also look into removing the vendor directory altogether. (similar to what prometheus does).

[brancz]

Ok. Not too strong of an opinion, so I'm ok with it. This does need a rebase and add the new tools added in #903 .

[jukie]

@brancz This should be ready now, could you please take a look?
Spoke too soon, I'll fix this.

[jukie]

I'm not yet sure why this is segfaulting

$ make validate-manifests
go install github.com/jsonnet-bundler/jsonnet-bundler/cmd/jb
cd scripts && jb install
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x540b42]

goroutine 1 [running]:
github.com/jsonnet-bundler/jsonnet-bundler/pkg.Install(0x6c0180, 0xc000086008, 0x101, 0xc0000ba2a0, 0x15, 0xc00007e0e0, 0x2, 0x4, 0x672a2c, 0x6, ...)
	/go/pkg/mod/github.com/jsonnet-bundler/jsonnet-bundler@v0.1.0/pkg/packages.go:58 +0x352
main.installCommand(0x672a2c, 0x6, 0x0, 0x0, 0x0, 0x7)
	/go/pkg/mod/github.com/jsonnet-bundler/jsonnet-bundler@v0.1.0/cmd/jb/main.go:295 +0x9ff
main.Main(0xc000072058)
	/go/pkg/mod/github.com/jsonnet-bundler/jsonnet-bundler@v0.1.0/cmd/jb/main.go:93 +0x712
main.main()
	/go/pkg/mod/github.com/jsonnet-bundler/jsonnet-bundler@v0.1.0/cmd/jb/main.go:61 +0x22
make: *** [Makefile:152: scripts/vendor] Error 2

[brancz]

The jb version must be master, not v0.1.0.

[jukie]

Alright it's actually ready this time, sorry about that.

[tariq1890]

Thank you for your PR @jukie. Just one review comment needs addressed. Once that is done, please squash the commits.

[jukie]

Which review comment is that? I applied your suggestion of removing GO111MODULE=on from the go install lines in the Makefile and that appears to be the only one on this PR. Was there something else I need to change?

[tariq1890]

The copyright header in tools.go has the wrong year

[tariq1890]

/lgtm
/approve

Thank you :) @jukie

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Jukie, tariq1890

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [tariq1890]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment