Manage our tools' dependencies in a structured way

[mlavacca]

What would you like to be added:

We have many dependencies in our hack script that often do not get updated. A non-exhaustive list follows:

• gateway-api/hack/verify-crds-kind.sh

  Lines 48 to 49 in cb846ce

  	(cd $GOPATH && go install sigs.k8s.io/kind@v0.20.0) || res=$?

• gateway-api/hack/verify-golint.sh

  Lines 21 to 22 in cb846ce

  	readonly VERSION="v1.57.2"
  	readonly KUBE_ROOT=$(dirname "${BASH_SOURCE}")/..

• gateway-api/hack/verify-yamllint.sh

  Lines 21 to 22 in cb846ce

  	readonly VERSION="1.29.0"
  	readonly KUBE_ROOT=$(dirname "${BASH_SOURCE}")/..

We need to discover all these dependencies and set up a way to either

• centralize them in a unique place easier and quicker to manage and update, or
• use an automatic tool to automatically bump them, such as renovate

[shaneutt]

/priority important-longterm
/help

[k8s-ci-robot]

@shaneutt:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/priority important-longterm
/help

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-sigs/prow repository.

[pmalek]

centralize them in a unique place easier and quicker to manage and update, or
use an automatic tool to automatically bump them, such as renovate

Why not both?

I'd suggest the following approach:

• put tools names and versions in 1 structured file ( e.g. a yaml called .tools_versions.yaml)
• use those from Makefile using a tool like yq
• add renovate annotations to the file so that these tools are kept up to date

In order to keep a unified interface for installing and running the tools we can leverage something like mise which will handle installing these tools' binaries. The only requirement for end user will be to have mise installed. Everything else will be handled by the tooling.

We follow a similar approach in
https://github.com/Kong/gateway-operator/blob/d401801b2b98bd771b841dc9af49073c1722cf1d/.tools_versions.yaml and it has worked well for us. I'd be happy to contribute this change if there's a consensus that this is the correct way forward.

[mlavacca]

centralize them in a unique place easier and quicker to manage and update, or
use an automatic tool to automatically bump them, such as renovate

Why not both?

I'd suggest the following approach:

* put tools names and versions in 1 structured file ( e.g. a yaml called `.tools_versions.yaml`)

* use those from `Makefile` using a tool like `yq`

* add renovate annotations to the file so that these tools are kept up to date

In order to keep a unified interface for installing and running the tools we can leverage something like mise which will handle installing these tools' binaries. The only requirement for end user will be to have mise installed. Everything else will be handled by the tooling.

We follow a similar approach in https://github.com/Kong/gateway-operator/blob/d401801b2b98bd771b841dc9af49073c1722cf1d/.tools_versions.yaml and it has worked well for us. I'd be happy to contribute this change if there's a consensus that this is the correct way forward.

Yep, this approach makes a lot of sense to me. Just want to check with the other maintainers to see if they are on board

/cc @shaneutt @robscott @youngnick

[shaneutt]

I am not opposed to us giving this a try, I do think we'll want to document it perhaps a bit "excessively".

[youngnick]

Agreed, it seems a little Rube-Goldberg-y to me, but seems worth trying as well.