Renovate: Support for Kustomize Image Tags and Remote Bases

[moredhel]

What would you like Renovate to be able to do?
We are looking to integrate renovatebot into our flow for all version-related functionality.

To do this we need to tackle one key piece of functionality which is support Kustomize.

Describe the solution you'd like
We would like to support two pieces of functionality for Kustomize:

1. Kustomize remote bases
2. Kustomize Image Tags

implemented as two separate managers (similar to how the terraform managers are implemented).

Describe alternatives you've considered
The current kubernetes plugin doesn't support this filetype, I considered adding it there, but opted to keep it separate as they are orthogonal. Kustomize aims to fill the same niche as helm.

Additional context
I have started work on implementing the above integration and wanted to get early feedback on if this is the correct direction to be going with it as there seems to be a fair amount of internal restructuring going on at the moment.

I aim to have a working PR up by the end of the week that anyone is welcome to play around with & provide feedback.

If you have any thoughts about things that I should definitely be avoiding, or I should avoid implementing this completely, please let me know.

All feedback is welcome.

Thanks!

[rarkins]

Hi, welcome to the project.

First of all, are the bases/tags all regular Docker images/tags? i.e. no new datasource required?

Second, are bases and tags defined within the same file(s), or kept logically separate? Separating managers is typically not desirable, but we do it sometimes.

[mikebryant]

kustomize bases are git repositories, so might be able to use the existing gitlab/github releases datasource? e.g. https://gitlab.com/mikebryant/house/-/blob/88a6da9da4625095463eb0f9a058babe2d2e80b3/flux/kustomization.yaml#L10 - the ref there is a git tag

[moredhel]

Hi Rarkins,

Thanks.

Regarding the tags, yes, they are essentially dockertags with everything before the : stripped off, so I will be reusing that functionality.

for the bases, it's a bit different and it's possible to reference a git repository + a subdirectory of the git repository for example two valid remote bases would be:

• [email protected]/renovatebot/renovate.git?ref=v1.0.0
• [email protected]/renovatebot/renovate.git//deploy/kustomize?ref=1.0.0

with a reference to the tag/sha otherwise defaulting to master.

I'm happy to bundle both managers into a single one for kustomize, I don't foresee that being problematic.

[rarkins]

@mikebryant probably not ok to use gitlab/github releases because those are are a subset of tags. We do have github tag support already though. One decision is:

• Do we start by supporting github.com-only and use the existing github tags datasource, or
• Do we use a generic "git refs" datasource and attempt to cover all use cases from the beginning?

[moredhel]

@rarkins I have an initial copy working off git-tags, to support a wider range of use-cases/avoid lockin to supported 'hubs'.

I believe that it will be sufficient for covering the functionality of how I see most usages of kustomize remote refs.

If we see a need for different versioning schemes (such as directly referencing a sha/tracking a branch) then that can be done, but I would prefer to keep this as unsurprising as possible.

My implementation can be extended to conditionally switch to the github/lab datasource if detected to improve performance, but perhaps that isn't required for an initial version & can be seen as a future enhancement.

What are your thoughts?

[rarkins]

I think keep it all as git tags for now, if that's working.