workflows: update helm release trigger, add helm chart testing, update image.tag on zigbee2mqtt release

[tamcore]

To make this possible, we're overriding the containers command and livenessProbe, since it's not possible to get the instance into a health state without having a zigbee adapter available. So we're basically just testing if the chart renders correctly and is installable on the most recent 3 Kubernetes versions.

Also fixed the OnZigbee2MQTTRelease workflow, to also update the .image.tag value (would close #12 then)

[jlpedrosa]

If you want/need to make the healthcheck configurable, let's make it in another PR, so we can reason through things more orderly please.

[tamcore]

Split out command and livenessProbe into #18, which is now a pre-requisite of this PR.

[jlpedrosa]

If we are going to tests those versions, pronably we should also limit the versions supported on Chart.yaml.

[tamcore]

Never seen it handled that way. I think testing against the latest 3 kubernetes versions is just fine. Paired with requiring any version that is not considered EOL.

[jlpedrosa]

@tamcore I think you didn't get my point. I'm trying to say that we should update the chart.yaml to 1.29.0 min version as part of this PR. With your PR, we are kinda supporting it better.

[jlpedrosa]

here:

zigbee2mqtt-chart/charts/zigbee2mqtt/Chart.yaml

Line 6 in 405f3e4

kubeVersion: ">=1.26.0-0"

[tamcore]

I did understand you. But the value you linked only makes sense, when the chart uses api versions that are not available on older versions. I.e. Ingress bellow 1.19. There's no reason to artificially limit it to exclusively what's being tested. The chart will install just fine in ubernetes 1.21, even though for whatever reason 1.26 is defined as the minimum version.

[jlpedrosa]

I still think makes sense since this is what we are supporting. The same GVK adds some fields in some version (sometimes by gates), I think it make sense that we test what we suport and we put on the manifests what we support.