ko apply doesn't error out when import path is incorrect

[dprotaso]

I mistyped a package name when specifying my container image. This caused ko to apply a yaml configuration with an non-existent image.

It would be nice if ko checked if the images I'm applying exist in my image registry and error out if they do not.

[jonjohnsonjr]

What do you mean by "exist in my image registry"? Most of the time I would think those images don't exist in your registry until you run ko apply, no?

[imjasonh]

It sounds like the issue is that if my YAML includes something like:

image: gihtub.com/user/repo/cmd/foo  # <-- typo!

Then ko resolve will not build an image for that incorrect importpath, and instead will pass it through to the resolved output, where the image will fail to be pulled, because it doesn't exist.

@dprotaso is that an accurate rephrasing of the issue?

[dprotaso]

Correct

…

On Wed, 30 May 2018 at 22:28 Jason Hall ***@***.***> wrote: It sounds like the issue is that if my YAML includes something like: image: gihtub.com/user/repo/cmd/foo # <-- typo! Then ko resolve will not build an image for that incorrect importpath, and instead will pass it through to the resolved output, where the image will fail to be pulled, because it doesn't exist. @dprotaso <https://github.com/dprotaso> is that an accurate rephrasing of the issue? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/google/go-containerregistry/issues/180#issuecomment-393381649>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIgtyG7Vt9DvtMfo11UztY3_O-482Qks5t31VJgaJpZM4UTUxI> .

[mattmoor]

tl;dr I'm certainly open to suggestions, but I'm unsure of how to robustly handle this.

There is certainly an angle here where we could introduce schema-sensitivity and special cases certain common patterns (e.g. .spec.image), but there are other patterns it would miss (e.g. sidecar images passed by flags).

One interesting case would be: what if I'm using ko apply -f foo.yaml, but the image: ... of foo.yaml is a pre-published image (NOT an import path)? Perhaps ko is a nop for this resource, or perhaps it is an instance of the latter example above (the image reference is a flag).

My guiding principle with ko has been to bias towards go idioms, but I'm not sure the go tool's DevX is much better (it would fail on a dependency not found, as we're failing on a container not found).

Does that make sense? WDYT?

[jonjohnsonjr]

This would complicate things, but we could log a warning if the edit distance of an image: string is <= 2 away from something in $GOPATH/src but skipped by ko?

We could also just do:
log.Printf("Skipping %q because no match found under %q", imageRef, src)

If you're using a pre-published image, no harm in logging that. If you expect ko to publish everything, you might see that?

Maybe even a --strict flag?

I went back and forth with dgageot on something similar... maybe we could adopt skaffold's strategy? Anything with an explicit tag/digest is expected to be skipped, but importpaths would not have those, so we could error on any reference with an implicit identifier that isn't ko-buildable. See some discussion in GoogleContainerTools/skaffold#565.

[jonjohnsonjr]

Fixed by #58

[vickynarang01]

I am getting an error on firing this command: ko resolve -f deployment.yaml

Attached a deployment yaml here for reference and the output of the command.

Error: error processing import paths in "deployment.yaml": error resolving image references: found strict reference but ko://github.com/vickynarang01/helloworld is not a valid import path: no required module provides package github.com/vickynarang01/helloworld; to add it:

Don't understand what's wrong here

[imjasonh]

There are a few things that could cause this:

• Is the repo checked out in your $GOPATH?
• I see the repo isn't using go modules, running go mod init github.com/vickynarang01/helloworld then ko resolve again should help.

[vickynarang01]

Thanks a tonne @imjasonh this issue is now resolved I have checked this into a new repository - https://github.com/vickynarang01/go-ko