search

kubernetes-sigs / gateway-api

Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
https://gateway-api.sigs.k8s.io
Apache License 2.0
1.86k stars 482 forks source link

Manage our tools' dependencies in a structured way #3318

Open mlavacca opened 2 months ago

mlavacca commented 2 months ago

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:

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

shaneutt commented 2 months ago

/priority important-longterm /help

k8s-ci-robot commented 2 months ago

@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:

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](https://github.com/kubernetes-sigs/gateway-api/issues/3318): >/priority important-longterm >/help Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
pmalek commented 4 days ago

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:

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 commented 4 days ago

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 commented 4 days ago

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

youngnick commented 4 days ago

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