Hi. I am relying on
helm test in my ci/cd pipeline. It feels very random since I sometimes get a
bad address host:port response from
wget. I have no idea why this is happening every 20th time. Any advices?
every 20th was of course an example. It is very random. Is there a reliable way of testing services that I’m not aware of?
I have readiness and liveness probes setup on the deployment.
anyone else ever run into issues where you deploy a helm chart with a new image, but because of an application error, you redeploy the previous stable image, but the new image version persists? i.e running basically these two commands:
$ helm upgrade blah --set "imageTag=1.2.4" \## application error on version 1.2.4 $ helm upgrade blah --set "imageTag=1.2.3"
on paper, i’d think the image at this point should be 1.2.3, but i’ve run into the case where it continues to persist 1.2.4. i feel like helm shouldn’t care about your image tags and their semver versions and whether youre incrementing or decrementing the image version, and this shouldnt be happening?
I don’t quite follow.
helm doesn’t know what
imageTag means. it doesn’t know what any “value” means.
most likely some subtle logical bug.
does the helm status flip to
@Erik Osterman (Cloud Posse) exactly! which is why it’s so weird to me. but this never happens when we deploy forward (i.e. v1.2.3 -> v1.2.4) and we run hundreds of deployments a day but i’ve noticed it happen on rare occasions when we deploy backwards. (v1.2.4 -> v1.2.3)
helm deploys successfully so no
theres a beta out
What’s this I hear about Helm 3 not needing Tiller?
That’s been the plan for a long time
how are you guys handling the
Error: "blah" has no deployed releases when a helm install gets in a failed state? I Know you can run
delete --purge but thats not very ideal