the idea is to remove the istioctl from the source control, as the bug describes. For that:

use a deployment with istioctl, copy it's istioctl binary to host and do exactly what we used to do until now

copy istioctl from the pod to the host

the idea here is to delete the istioctl binary that we have in our repo and get it from an image from istio. Such an image is the one here

added #1637 for follow-up as unlike the other images, this is using a different istio version and also isn't pulled locally first (so it will be pulled from within k3s)

to be honest, we are not there yet. thx to your issue, I've realized that we are not using any github cache for these images (among some other that we use in integration tests), so I need to fix that one too.

be careful caching, as in zipkin we had a security glitch that caused a lot of headache. We now have this in all our workflows.

      # Don't attempt to cache Docker. Sensitive information can be stolen
      # via forks, and login session ends up in ~/.docker. This is ok because
      # we publish DOCKER_PARENT_IMAGE to ghcr.io, hence local to the runner.

Between first time we met and now, I understand why we are loading to k3s.

Basically, this:

• prevents double-downloading of well-known images (like istio), as they can use the copy from local docker
• allows you to use the image you just built which isn't yet published

So, theses are still helpful regardless of github caching

thank you for the heads-up! and thank you a lot for your issue with this one. From what I remember the change to using k3s was the biggest PR we had, with months of work, so things might have slipped here and there

I have been using k3s in go, and it also took me a very long time to understand all the nuance. I believe it must have been a lot more work before, as few if any must have been using it in testcontainers when you did this.