Fix 1634 #1635
Fix 1634 #1635
Conversation
Configure Renovate
| spec: | ||
| containers: | ||
| - name: istio-ctl | ||
| image: istio/istioctl:1.20.1 |
There was a problem hiding this comment.
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
| istioctlManifests(Phase.CREATE); | ||
|
|
||
| String istioctlPodName = istioctlPodName(); | ||
| K3S.execInContainer("sh", "-c", |
There was a problem hiding this comment.
copy istioctl from the pod to the host
| @@ -0,0 +1,21 @@ | |||
| apiVersion: apps/v1 | |||
There was a problem hiding this comment.
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
|
@ryanjbaxter enhancement that was raised yesterday by @codefromthecrypt |
| spec: | ||
| containers: | ||
| - name: istio-ctl | ||
| image: istio/istioctl:1.20.5 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
No description provided.