CI: minikube install smoke test flaky

[vdice]

The minikube install smoke test as part of ci.yaml has been failing recently, for example https://github.com/spinframework/runtime-class-manager/actions/runs/18860583134/job/53818099767?pr=462

Try to repro locally and fix. Not sure if test harness or actual issue.

[Shunpoco]

I found that installer pod(s) is in Init:Error status even if the smoke test successfully finishes.
For example, https://github.com/spinframework/runtime-class-manager/actions/runs/22153657032/job/64051784421 was in success, but in run Spin App, there is one installer pod in Init:Error status.

NAMESPACE     NAME                                         READY   STATUS       RESTARTS   AGE
default       wasm-spin-5f4dbbf98b-7cxw5                   1/1     Running      0          2s
kube-system   coredns-668d6bf9bc-nm9wd                     1/1     Running      0          45s
kube-system   etcd-minikube                                1/1     Running      0          50s
kube-system   kindnet-px2nr                                1/1     Running      0          45s
kube-system   kube-apiserver-minikube                      1/1     Running      0          50s
kube-system   kube-controller-manager-minikube             1/1     Running      0          51s
kube-system   kube-proxy-6s5hw                             1/1     Running      0          45s
kube-system   kube-scheduler-minikube                      1/1     Running      0          51s
kube-system   storage-provisioner                          1/1     Running      0          49s
rcm           minikube-spin-v2-install-6mhxh               0/1     Completed    0          12s
rcm           minikube-spin-v2-install-z24sm               0/1     Init:Error   0          22s # This one
rcm           rcm-runtime-class-manager-7fbdf986c6-ljt7d   1/1     Running      0          34s

Then I tried the same commands on my local, and reproduced this Init:Error.
An installer pod has a downloader as an init container, but it seemed to fail downloading a shim from GitHub.
I stripped -s option from curl here and checked what the error container said:

$ k logs -n rcm minikube-spin-v2-install-2qv7x -c downloader
2026-02-18T18:50:15     INFO    start downloading shim from  https://github.com/spinframework/containerd-shim-spin/releases/download/v0.22.0/containerd-shim-spin-v2-linux-x86_64.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0
curl: (6) Could not resolve host: github.com (Could not contact DNS servers)

I think the installer pod was deployed before minikube's DNS server (coredns) was fully launched, then it causes the error and forces the installer Job to create a new pod. (And finally, it causes a timeout in the CI).

I don't fully understand why only minikube has this issue, but possible reasons are:

• Minikube somehow takes a longer time to launch coredns, and/or
• Other environments also have the issue (so there might be some Init:Error pods), but their new pod scheduling or pod creation is much quicker than minikube

I think we can mitigate this issue by those two works:

1. Set a longer timeout for the verify step, and
2. Add a retry logic in downloader's shellscript (I think we should have it even if we don't have this problem)

[Shunpoco]

Ah, the first one is already done by #589 😄

[vdice]

@Shunpoco Wow, thank you for taking the time to share your investigations! Incredibly helpful.

Yes, #589 is just a band-aid, but you point out a great idea to more properly address the underlying issue in 2. add retry logic. I'll create the issue. If you are keen, feel free to work on it!