-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate why SanitizeImageName isn't being called #5505
Comments
Ah! @PriyaModali and I had noticed that the image wasn't being rebuilt (#5500) — that it was being cached. It looks like SanitizeImageName() is called from the imageReplacer: skaffold/pkg/skaffold/kubernetes/manifest/images.go Lines 80 to 85 in 7aaa1c7
which is called to replace image references. I wonder if cached images are not included in the built images passed in here: skaffold/pkg/skaffold/kubernetes/manifest/images.go Lines 60 to 64 in 7aaa1c7
|
I can look into this as part of the work for #5611 |
I wasn't able to reproduce the issue described in GoogleContainerTools#5492 and GoogleContainerTools#5505, so this change restores the import path with the uppercase characters and the `ko://` prefix in the custom build example. I had to tweak some values to get the integration tests to run, because I don't have access to the `k8s-skaffold` project. Let's see if the build passes. Additional minor changes: - Bump the ko version in the custom build example. - Add the full path to the ko binary in the custom build script, in case `$GOPATH/bin` is not on the `PATH`. Once we move to Go 1.16 for our builds, we can use the `go install` command to install ko in the custom build shell script.
I wasn't able to reproduce the issue described in GoogleContainerTools#5492 and GoogleContainerTools#5505, so this change restores the import path with the uppercase characters and the `ko://` prefix in the custom build example. I had to tweak some values to get the integration tests to run, because I don't have access to the `k8s-skaffold` project. Let's see if the build passes. Additional minor changes: - Bump the ko version in the custom build example. - Add the full path to the ko binary in the custom build script, in case `$GOPATH/bin` is not on the `PATH`. Once we move to Go 1.16 for our builds, we can use the `go install` command to install ko in the custom build shell script.
…ple (#6286) * Restore import path with uppercase characters I wasn't able to reproduce the issue described in #5492 and #5505, so this change restores the import path with the uppercase characters and the `ko://` prefix in the custom build example. I had to tweak some values to get the integration tests to run, because I don't have access to the `k8s-skaffold` project. Let's see if the build passes. Additional minor changes: - Bump the ko version in the custom build example. - Add the full path to the ko binary in the custom build script, in case `$GOPATH/bin` is not on the `PATH`. Once we move to Go 1.16 for our builds, we can use the `go install` command to install ko in the custom build shell script. * Look for ko binary in GOPATH/bin It's difficult to know what's on the `PATH` in different environments. This change to the custom builder example looks for the ko binary in the `GOPATH/bin` directory. * Remove tagPolicy from custom builder example Hypothesis: `tagPolicy: sha256` doesn't behave correctly with images sideloaded into kind snf k3d. Also fix conditional in custom build example shell script to prevent recompiling ko each time. * Sanitize image names before deciding what to load I was able to reproduce the issue locally and work out a fix. I'd be happy for feedback on whether I've chosen the right place to fix it. When determining which images to sideload (for kind and k3d), we compare `localImages` and `deployerImages`. The former from `skaffold.yaml`, and the latter from Kubernetes manifest files. The image names from Kubernetes manifests are sanitized in `pkg/skaffold/kubernetes/manifests/images.go#L51` (and `L113`) in the call to docker.ParseReference. The same doesn't happen to image names from `skaffold.yaml`. This change sanitizes these image names just for determining whether to sideload the images. In other parts of the code we look up image pipelines from `skaffold.yaml` using the image name, so I was hesitant to change how `localImages` is used (with 'raw' image names). The hypothesis from the previous commit is disproven, so I'm adding back the `sha256` tag policy in the custom builder example. To make the test case easier to identify from the build logs, I renamed the pod in the custom builder example. New hypothesis: Could this be related to the issues some users are reporting with images not being sideloaded when using Helm? E.g., #5159
SanitizeImageName
isn't being called which is causing the custom test to fail withko:
images.We need to investigate why SanitizeImageName isn't being called.
The text was updated successfully, but these errors were encountered: