* Allow ko to produce estargz layers.
This pulls in the latest google/go-containerregistry, which enables folks to set `GGCR_EXPERIMENT_ESTARGZ=1` to enable `ko` to start producing layers compatible with the estargz format, which enables the containerd estargz-snapshotter to lazy-load parts of images.
* Add README
This simplifies the logic for creating layers and relies on the new option instead of pre-gzipping (and gunzip being faster). The net effect of this should be the elimination of an extra gunzip, but it should not materially impact the memory pressure because we were ALREADY caching the gzipped layers in-memory, we were just doing it on the caller side, which provided less benefit!
* Refactor the publish.Namer to produce the full repo name.
* Add --naked to have image publishing use ${KO_DOCKER_REPO}:tag
* Change flag name, add disclaimer
The "require" is behind the version in "replace", and since cli-runtime references the package mentioned in the errors we are seeing, rule this out as a source!
Turns out I broke this. Thanks to @bobcatfish for reporting the issue.
With this change:
```
ko resolve -Pf cmd/ko/test/test.yaml > /dev/null
2020/05/04 08:44:35 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/cmd/ko/test
2020/05/04 08:44:36 Building github.com/google/ko/cmd/ko/test
2020/05/04 08:44:37 Publishing gcr.io/mattmoor-knative/github.com/google/ko/cmd/ko/test:latest
2020/05/04 08:44:39 Published gcr.io/mattmoor-knative/github.com/google/ko/cmd/ko/test@sha256:ee655510172b429dbce619fc69677621d71cb824cbbf2a21746d700127257ec4
```
I can cut v0.5.1 once this lands.
This change more or less completely changes how `ko://` is handled internally to `ko`, but the user-facing changes should only be net-positive. `ko://` was previously stripped at the highest level, and the build logic was unaware, which had some undesirable diagnostic/functional implications that are collectively addressed in this change.
With this change, the `ko://` prefix is preserved and passed to the build logic, which internally parses a new `reference` type (this was useful to have Go's type checker find all of the places that needed fixing). The main functional differences are:
1. If a reference is prefixed with `ko://` we will now fail fast in `IsSupportedReference` regardless of whether `--strict` is passed.
2. If a reference is prefixed with `ko://` it will bypass the prefix check, which allows the use of `ko://github.com/another/repo` that references a vendored binary package.
For `2.` the absence of the module prefix causes the filtering logic Jon introduced to avoid the reference. This was critical for efficiency when `ko://` isn't around because we feed every string in the yaml through it, but when the user has explicitly decorated things it's the perfect thing to be sensitive to.
Fixes: https://github.com/google/ko/issues/146
Fixes: https://github.com/google/ko/issues/152
* Viper keys are case insensitive.
This fixes an issue where import paths with uppercase (github.com/GoogleCloudPlatform 👀) were being canonicalized by Viper to all lowercase and the baseImageOverrides in `.ko.yaml` were failing to properly identify the base image.
I hit this in: https://github.com/tektoncd/pipeline/pull/2435 trying to opt some of the GCP images out of `:nonroot`.
This also adds some logging to a place where I see a lot of folks have issues with `ko` where we swallow an error. I hit it experimenting with variants on the `ko publish` import path, and added the logging to debug.
* Drop the new log statement
Matt Moore