Moves helm from being downloaded from curl, to being installed via hack/tools

[JoshVanL]

No description provided.

[jetstack-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoshVanL

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 [JoshVanL]

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

[munnerz]

How come we want to do this? It seems like it's quite a bit more expensive to build helm from scratch than it is to curl it, and I'm slightly concerned about awkward dependency conflicts in future too (what with us depending on controller-tools, kind, code-generator and helm in one go.mod).

[JoshVanL]

The intention is to have as much of our version management in one tooling (go modules), rather than split across multiple (go modules, Makefile vars + curl).

This helps to ensure tool versions don't get left behind.

[SgtCoDFish]

I'm a pretty strong -1 on actively changing from downloading binaries to building using go build. I wouldn't see much of a need to go out and change a Makefile which uses go build already, but I don't think we should go the other way and replace curl with go build. IMO it's a step backwards.

I don't see how it's any easier to bump a version number in a go.mod than it is to bump a version number in a Makefile - especially if it runs the risk of dependency hell as @munnerz points out.

IMO the ideal situation is downloading prebuilt binaries and checking their hashes to ensure they've not been tampered with. Fewer things that can go wrong, far less CPU usage, far less chance of Go dependency hell in the future. Also much easier to add retries with curl if something goes wrong or there's a network flake.

The intention is to have as much of our version management in one tooling (go modules), rather than split across multiple (go modules, Makefile vars + curl).

I'd argue we have two sets of tooling in this PR; we have two go.mod files, one for the application and one for tools. I think it's totally reasonable to have tool dependencies versioned in the Makefile and application dependencies versioned in the go.mod.

[JoshVanL]

Hear where you are both coming from. Since you're both against the PR I'll close it.

I think nix could be a really good solution to all of our tooling needs (:tm:) across cert-manager. The massive downside is that 1. developers will need to install nix, and 2. the team would need to learn nix. I'll perhaps add this as an agenda item for a future meeting.

/close

[jetstack-bot]

@JoshVanL: Closed this PR.

In response to this:

Hear where you are both coming from. Since you're both against the PR I'll close it.

I think nix could be a really good solution to all of our tooling needs (:tm:) across cert-manager. The massive downside is that 1. developers will need to install nix, and 2. the team would need to learn nix. I'll perhaps add this as an agenda item for a future meeting.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.