Transient curl failures during kind/kubectl download abort the whole job (no retry)

[kaovilai]

What happened

run-e2e-test in velero-io/velero intermittently fails ~20s in, before any of the caller's own code runs, with:

Installing kind...
/opt/hostedtoolcache/kind/v0.32.0/amd64/kind/bin ~/work/velero/velero
curl: (35) Recv failure: Connection reset by peer

Run: https://github.com/velero-io/velero/actions/runs/29520226612/job/87696522473

Tracked on our side as velero-io/velero#10020.

Why this points at kind.sh

In kind.sh, install_kind(), install_kubectl(), and install_cloud_provider() all download via plain curl -sSLo with no --retry/--retry-all-errors flags, and the script runs under set -o errexit:

curl -sSLo "kind-linux-${arch}" "https://github.com/kubernetes-sigs/kind/releases/download/${version}/kind-linux-${arch}"

So any transient network blip (connection reset, DNS hiccup, etc.) during that single curl invocation fails the step immediately and takes down the whole job — even though nothing about the caller's own code is at fault. In our case, only 1 of ~29 matrix jobs failed on an otherwise green commit, which is consistent with a transient, non-reproducible network error rather than a real problem with the release artifact or caller config.

Suggested fix

Add curl retry flags to the download calls in install_kind, install_kubectl, and install_cloud_provider, e.g.:

curl -sSL --retry 5 --retry-all-errors --retry-delay 5 -o "kind-linux-${arch}" "..."

This is a small, low-risk change that would make the action resilient to exactly this class of flake for all consumers, rather than each consumer having to work around it individually.

Workaround

On our side we worked around this by dropping helm/kind-action@v1 in favor of installing the kind CLI directly with retrying curl and calling kind create cluster ourselves: velero-io/velero#10021. We'd rather use the action again once it retries on its own.

Note

Responses generated with Claude