<p>I am using helm in my CI to upgrade deployments with newer versions of charts.</p>

<pre><code>helm upgrade --wait --install .
</code></pre>

<p><strong>Expected behavior:</strong>
the --wait flag should wait for the readinessProbe defined in the new chart.
See also:
<a href="https://docs.helm.sh/helm/#helm-upgrade" rel="nofollow noreferrer">https://docs.helm.sh/helm/#helm-upgrade</a></p>

<p>However, it does not wait and simply deploys the new chart, even if the readinessProbe is failing.</p>

<p>Which results in a failed new chart and a killed old chart.</p>

<p>It has nothing to do with 
<a href="https://github.com/helm/helm/issues/3173" rel="nofollow noreferrer">https://github.com/helm/helm/issues/3173</a>, as the readinessProbe is properly executed and fails. But Helm does simply not wait for this.</p>

<p>Did anybody face issues like that? 
Thanks!</p>

<p>The Issue was fixed by setting the following Kubernetes yaml description inside the deployment ressource:</p>

<pre><code>  strategy:
   type: RollingUpdate
   rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0
</code></pre>

<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" rel="nofollow noreferrer">Kubernetes Deployment Documentation:</a></p>

<blockquote>
  <p>Note: The Deployment controller will stop the bad rollout
  automatically, and will stop scaling up the new ReplicaSet. This
  depends on the rollingUpdate parameters (maxUnavailable specifically)
  that you have specified. Kubernetes by default sets the value to 1 and
  .spec.replicas to 1 so if you haven’t cared about setting those
  parameters, your Deployment can have 100% unavailability by default!
  This will be fixed in Kubernetes in a future version.</p>
</blockquote>
