Support ko image references #4952
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4952 +/- ##
==========================================
- Coverage 72.36% 72.31% -0.05%
==========================================
Files 360 360
Lines 12527 12537 +10
==========================================
+ Hits 9065 9066 +1
- Misses 2800 2809 +9
Partials 662 662
Continue to review full report at Codecov.
|
`ko` supports replacing `image` manifest fields with the image names and digests of the built images. For this to work, the `image` field must contain the import path of the Go binary, prefixed by `ko://`. The prefix was optional prior to ko v0.6.0. Starting from v0.6.0, [the prefix is mandatory](https://github.com/google/ko/releases/tag/v0.6.0). This change allows Skaffold to use manifests containing ko image references, including those that use the prefix. Skaffold replaces the image name as expected when using ko via a custom `buildCommand`. It also handles Go import paths containing uppercase characters, e.g. `github.com/GoogleContainerTools/skaffold`, by lowercasing them. This means `ko` users can start using Skaffold without making changes to their manifests, and it allows these users to use both ko via Skaffold custom builder, and ko standalone (without Skaffold), side-by-side.
|
Hi @halvards , thanks for opening this PR! These changes look good to me :) Thanks for updating the example to match the changes. I'll run kokoro for this and if everything is good I think this should be good to go in. Do you have ideas for what first class support for |
|
@MarlonGamez I think we should hold off until @nkubala is back. It seems odd to embed specific tool strings that we don't directly support. |
|
@briandealwis yeah, that makes sense. I'll label it as do-not-merge for now then |
|
@nkubala would you be able to take a look at this. |
There was a problem hiding this comment.
sorry for the late reply on this one, talked with @jonjohnsonjr just to understand more of what's going on here and this seems fine. obviously it's not ideal to be hardcoding strings in like this, but because of the way we parse image references in skaffold our hands are sort of tied. ko treats github paths as image references, and even though they're technically not, they parse correctly with docker.ParseReference. the ko:// prefix unfortunately causes this to choke, so short of reworking our image reference parsing this is the best option.
because of the way ko's watcher works, first class support in skaffold is a whole different problem entirely :) it's an awesome way to build go apps though, so even though we don't "natively" support it in skaffold i think it's fine to merge this fix in the interim.
|
Thanks all, and yes sorry for not providing more context up front on the import path/image reference parsing issue! On the topic of watching, I was thinking that any further integration of ko into skaffold could use skaffold's watch implementation, rather than the one in ko? Maybe a discussion for another thread. |
|
@halvards definitely a discussion worth having, but this thread is probably too low visibility to get it any traction :) feel free to open another issue here or on the ko repo to further discuss |
This change ensures that image names from `skaffold.yaml` are sanitized even when the Skaffold default repo is not set. This is relevant for ko images with names that consist of the `ko://` scheme prefixed, followed by a Go import path that may contain uppercase characters, e.g., `ko://github.com/GoogleContainerTools/skaffold/cmd/skaffold`. Fixes: GoogleContainerTools#6675 Tracking: GoogleContainerTools#6041 Related: GoogleContainerTools#4952
This change ensures that image names from `skaffold.yaml` are sanitized even when the Skaffold default repo is not set. This is relevant for ko images with names that consist of the `ko://` scheme prefixed, followed by a Go import path that may contain uppercase characters, e.g., `ko://github.com/GoogleContainerTools/skaffold/cmd/skaffold`. Fixes: #6675 Tracking: #6041 Related: #4952
Description
kosupports replacingimagemanifest fields with the image namesand digests of the built images. For this to work, the
imagefieldmust contain the import path of the Go binary, prefixed by
ko://.The prefix was optional prior to ko v0.6.0. Starting from v0.6.0,
the prefix is mandatory.
This change allows Skaffold to use manifests containing
koimagereferences, including those that use the prefix. Skaffold replaces the
image name as expected when using
kovia a custombuildCommand.It also handles Go import paths containing uppercase characters, e.g.
github.com/GoogleContainerTools/skaffold/cmd/skaffold, by lowercasing them.This means
kousers can start using Skaffold without making changesto their manifests, and it allows these users to use both
koviaSkaffold custom builder, and
kostandalone (without Skaffold),side-by-side.
Related: #1958, #4098
User facing changes
Updates the custom builder
koexample to v0.6.0, and to use akoimage reference.Follow-up Work
First-class support for
kowould be great 😄