chore: use stable as default image

[fforootd]

No description provided.

[eliobischof]

I couldn't find any best practices for this.
The best thing IMO would be if we published additional docker tags for only major and minor versions, then set v2 as appVersion?

Edit: Then we would need release channels for each major version, like v2-stable?
In the meantime, I'd add stable as appVersion.

[fforootd]

Incorporated the changes

[fforootd]

I couldn't find any best practices for this. The best thing IMO would be if we published additional docker tags for only major and minor versions, then set v2 as appVersion?

Edit: Then we would need release channels for each major version, like v2-stable? In the meantime, I'd add stable as appVersion.

Interesting, how do other established players like grafana, gitlab, ... do this?

[eliobischof]

Grafana, Cockroach and GitLab increment their chart versions when the app versions increment:

• [grafana] Upgrade Grafana to 9.0.4 and bump chart grafana/helm-charts#1633
• release: update CockroachDB version to 22.1.5 #85247 cockroachdb/helm-charts#259
• https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2712

[eliobischof]

If we want to have a fixed appVersion for a chart version too, maybe we should automate things.

[eliobischof]

I think we should publish a stable channel for the chart repository as a whole somehow

[fforootd]

I think we should publish a stable channel for the chart repository as a whole somehow

And when do we want to do this? In this PR, or should we proceed first with merging?

[eliobischof]

I think we should publish a stable channel for the chart repository as a whole somehow

And when do we want to do this? In this PR, or should we proceed first with merging?

I think we should close this PR, implement zitadel/zitadel#4219 instead and create a new issue for the charts stable channel. Edit: #36

[juliusrickert]

Using mutable image tags is considered to be an anti–pattern.

Firstly, you'd need to use a pullPolicy of Always, breaking in case of registry downtime or other issues.
Secondly, in case of a rollback, the image has been overwritten, so the rolled-back release may not work, or, potentially worse, different nodes could have different versions of the image.

Same goes for a Helm chart and an app version. Otherwise, it may be impossible to install an old version of the chart due to configuration changes or similar.

Automating the release process may be the way to go here. If the main application strongly adheres to semver, I think this should work.

[fforootd]

Using mutable image tags is considered to be an anti–pattern.

Firstly, you'd need to use a pullPolicy of Always, breaking in case of registry downtime or other issues. Secondly, in case of a rollback, the image has been overwritten, so the rolled-back release may not work, or, potentially worse, different nodes could have different versions of the image.

Same goes for a Helm chart and an app version. Otherwise, it may be impossible to install an old version of the chart due to configuration changes or similar.

Automating the release process may be the way to go here. If the main application strongly adheres to semver, I think this should work.

True, I agree with this. Although I think using a latest tag is fine for easy to start cases.

Since ZITADEL strictly uses semver it should be feasible to create new tags as needed for this helm chart.

Since @eliobischof is in vacation this week he will pick-up next week with this 😁

[fforootd]

@eliobischof can you have a look into this?

[eliobischof]

I still think it is a bad idea to use mutable tags by default because I don't assume the chart is just used in easy to start cases.

I would rather add a --set image.tag=latest option to the docs and automatically trigger chart releases when ZITADEL is released, regardless of the ZITADEL tags release channel. I can do it tomorrow, it's not a big deal.

[fforootd]

I still think it is a bad idea to use mutable tags by default because I don't assume the chart is just used in easy to start cases.

I do to, what I meant by looking into, is that we should automate the lifecycle of the helm chart depending on the ZITADEL release.

[eliobischof]

Replaced by #43