-
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
ko:// image references are broken #5492
Labels
Comments
PriyaModali
added
kind/bug
Something isn't working
area/build
priority/p2
May take a couple of releases
labels
Mar 4, 2021
PriyaModali
changed the title
Custom build example need to be updated
Custom build example is currently broken
Mar 5, 2021
This was referenced Mar 5, 2021
As far as I'm aware, it looks like the custom builder example should work, however, it seems like this piece of code from #4952 isn't being applied? skaffold/pkg/skaffold/docker/reference.go Lines 83 to 97 in 2e55bec
|
Merged
Closing again: #5505 is to investigate why |
briandealwis
changed the title
Custom build example is currently broken
ko:// image references are broken
Jun 10, 2021
halvards
added a commit
to halvards/skaffold
that referenced
this issue
Jul 26, 2021
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.
tejal29
pushed a commit
to halvards/skaffold
that referenced
this issue
Aug 11, 2021
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.
tejal29
pushed a commit
that referenced
this issue
Aug 11, 2021
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Custom build example is currently failing. See the attached error .
The text was updated successfully, but these errors were encountered: