* Add support for `--image-refs`
This change adds a new `--image-refs=FILE` flag that can be used to
direct `ko` to write a file containing a `\n` delimited list of published
references. In the common case, this will contain the list of digest
references, but if flags directing the use of tags are present this
will reflect the style of reference requested.
* Fix dates, interface check.
In the PR where we added concurrency we used a fixed length array to store
addendum to preserve the ordering from the base image when constructing the
final index. However, with `--platform=...` this list may be filtered, which
gives us `nil` entries in our addendum.
This filters `nil` entries prior to constructing the index.
Fixes: https://github.com/google/ko/issues/544
We were emitting package checksum hashes as `h1:{base64}`. `h1:` is a prefix that indicates "Hash 1", which is a SHA-256 based hash of the files, which is then base64 encoded as the suffix.
This change detects/strips the `h1:` prefix and re-encodes the base64 data as hex.
* Connect SBOMs with SPDX support.
This combines Jason's SPDX stuff and my SBOM stuff to support
SPDX-based SBOMs by default instead of our `go version -m`
invention.
* Make ko deps use SPDX by default
This adds functionality that enables the default publisher to
publish SBOMs (and later signatures and attestations) when the
`build.Result` is an `oci.SignedEntity`.
This also changes the `gobuild` logic to start producing
`oci.Signed*` as its `build.Result`s, so when executed we get an
SBOM for each architecture image.
For example, see the "Published SBOM" lines below:
```shell
2021/11/19 19:24:50 Using base gcr.io/distroless/static:nonroot for github.com/google/ko
2021/11/19 19:24:51 Building github.com/google/ko for linux/amd64
2021/11/19 19:24:52 Building github.com/google/ko for linux/arm64
2021/11/19 19:24:57 Publishing ghcr.io/mattmoor/ko:latest
2021/11/19 19:24:58 existing blob: sha256:c78c74e7bb4a511f7d31061fbf140d55d5549a62d33cdbdf0c57ffe43603bbeb
2021/11/19 19:24:58 existing blob: sha256:4aa59d0bf53d4190174fbbfa3e9b15fdab72e5a95077025abfa8435ccafa2920
2021/11/19 19:24:58 ghcr.io/mattmoor/ko:sha256-d2bc030f5ed083d5e6a30a7969c9a8e599511b8d7a6e20695bf5ea029b6e2c3f.sbom: digest: sha256:c67ec671aaa82902e619883a7ac7486e6f9af36653449e2eb030ba273fe5a022 size: 348
2021/11/19 19:24:58 Published SBOM ghcr.io/mattmoor/ko:sha256-d2bc030f5ed083d5e6a30a7969c9a8e599511b8d7a6e20695bf5ea029b6e2c3f.sbom
2021/11/19 19:24:58 existing blob: sha256:c78c74e7bb4a511f7d31061fbf140d55d5549a62d33cdbdf0c57ffe43603bbeb
2021/11/19 19:24:58 existing blob: sha256:4aa59d0bf53d4190174fbbfa3e9b15fdab72e5a95077025abfa8435ccafa2920
2021/11/19 19:24:59 ghcr.io/mattmoor/ko:sha256-b74c230f20efd94981e5fd823bacc23cbd71055a1b3b6a0893152b398c67743b.sbom: digest: sha256:c67ec671aaa82902e619883a7ac7486e6f9af36653449e2eb030ba273fe5a022 size: 348
2021/11/19 19:24:59 Published SBOM ghcr.io/mattmoor/ko:sha256-b74c230f20efd94981e5fd823bacc23cbd71055a1b3b6a0893152b398c67743b.sbom
2021/11/19 19:24:59 existing blob: sha256:3f7e3c6765a6abc682cd40ea256fbea5c1d4debbc07659efbc0dedc13eee0da6
2021/11/19 19:24:59 existing blob: sha256:250c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542
2021/11/19 19:24:59 existing blob: sha256:e8614d09b7bebabd9d8a450f44e88a8807c98a438a2ddd63146865286b132d1b
2021/11/19 19:24:59 existing blob: sha256:7067b1bc6f9ce59f3a4ed2216946ebbb27a4f7a102f55d96c6af1dc90e77b510
2021/11/19 19:25:00 ghcr.io/mattmoor/ko@sha256:d2bc030f5ed083d5e6a30a7969c9a8e599511b8d7a6e20695bf5ea029b6e2c3f: digest: sha256:d2bc030f5ed083d5e6a30a7969c9a8e599511b8d7a6e20695bf5ea029b6e2c3f size: 751
2021/11/19 19:25:01 existing blob: sha256:250c06f7c38e52dc77e5c7586c3e40280dc7ff9bb9007c396e06d96736cf8542
2021/11/19 19:25:02 pushed blob: sha256:121c637d5c84562b51404a6f71c1f995ad059740293a3911a0dc33eb223e41a4
2021/11/19 19:25:02 pushed blob: sha256:859e03b7461b2a512159493ef1504d2859ed37c05ed1ef781ff98394ea4799b5
2021/11/19 19:25:02 pushed blob: sha256:d1b55c3db0f16b5056776c6d2c279efd16d28dbf1aae3eef1f3f9b7551d1f490
2021/11/19 19:25:03 ghcr.io/mattmoor/ko@sha256:b74c230f20efd94981e5fd823bacc23cbd71055a1b3b6a0893152b398c67743b: digest: sha256:b74c230f20efd94981e5fd823bacc23cbd71055a1b3b6a0893152b398c67743b size: 751
2021/11/19 19:25:03 ghcr.io/mattmoor/ko:latest: digest: sha256:e4466a7dd9be66c7c1b43a8ecc19247041ece232407a14e3d6ea3c51d2561a71 size: 529
2021/11/19 19:25:03 Published ghcr.io/mattmoor/ko@sha256:e4466a7dd9be66c7c1b43a8ecc19247041ece232407a14e3d6ea3c51d2561a71
ghcr.io/mattmoor/ko@sha256:e4466a7dd9be66c7c1b43a8ecc19247041ece232407a14e3d6ea3c51d2561a71
```
The "SBOM" being attached in this change is the raw output of `go version -m`,
which we will convert to one of the standard formats in a subsequent change.
* 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