traefik-helm-chart

traefik-helm-chart copied to clipboard

Welcome!

• [X] Yes, I've searched similar issues on GitHub and didn't find any.
• [X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

Please make this Chart (e.g. appVersion) track the https://github.com/traefik/traefik releases.

Even thou we can set the image.tag chart value, that makes it harder to the user to known which chart versions are compatible with which traefik versions. It also means, we'll end up updating two versions, instead of one.

Hello,

The appVersion is mainly updated on a minor version (v1.X.y) of Traefik, the bug fix releases (v1.x.Y) of Traefik are always compatible with the minor version.

@ldez why? It much more practical to have a chart release for each Traefik release. This is common practice across helm community. Majority of chart users don't track traefik releases, they do track helm repo. Your approach breaks end user release cycle, where I have to follow patch releases, but skip the minor and major.

why?

"The time is the limit" but as the project is open source, everybody can create a PR to update the default value of the appVersion.

everybody can create a PR

Problem with this, that community contributions remain stale for months without review. While PRs from traefik team members merged in seconds, like this https://github.com/traefik/traefik-helm-chart/pull/614.

we are working on a new maintenance mode.

A PR that just updates the version of Traefik is easy to review, so yes all the PR are not merged at the same speed but it's more related to the content than the authors.

I could help with the CICD of this... perhaps have something like dependapot update the docker tag for traefik and raise a PR that does some basic tests to ensure things are working? Even just getting the PR up might be nice.

Yes, sure. It would be awesome, @shadycuz !

@mloiseleur

Here are the rough steps that would need to happen.

1. The maintainers of this repo would need to enable dependabot or renovate to handle dependency updates. I personally prefer renovate and it would probably do a better job but I think dependabot might also work for this.
2. We would need to create a dummy Dockerfile with the line from traefik:v2.9.6 inside the repo. This is the file that dependabot/renovate will watch and if a new version is released than a new PR will be opened.
3. This is the tricky part, we will need to use the CICD pipeline to grab the new version, say 2.9.7 for example and update the charts appVersion variable. This will involve committing this change back to the repo. Which is kinda tricky because you can't do it with the normal pipeline token you will need to create some kind of "bot" github user and generate an API token for that user and save it in your GitHub secrets. That way the pipeline can use the bot users API key to commit files back.

That would be a really good first step. If traefik maintainers are willing to help out on there end than I can submit the PR with these changes. We could start working on this now and release this feature sometime after the change to traefik 3.0. Because I'm pretty sure dependabot/renovate will try to give us that version very soon.

Once this work is done you could take this even further and add some functional testing. Once those tests have passed you could automatically merge and create a github release with release-drafter.

That seems quite complex.

In renovate doc, they provide an example to update appVersion, wdyt about it ?

@mloiseleur, oh yes. That is perfect. Here is an example of it in use. So all Traefik maintainers would need to do is enable renovate on this repo. Than we could submite a PR where we leave a comment above the appVersion like with the name of the Docker repo/image.

Yes, sure. Thanks for the example ! Currently, we have other priorities but we'll do it as soon as we can.

I'm reopening it because current PR opened by renovate increments only appVersion and not Chart version. See this PR for instance.