MultiPublisher now returns an error when it's configured with no
publishers, and resolver.go now appends a nop publisher when it's
configured not to publish, that simulates a publish without actually
pushing any images.
.
KO gives an error for the wrong go versions. The error is not very verbose.It is diffcult to decipher the logs of the error given. As a developer, adding a note to the installation process would prevent me from stumbling onto this issue.
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!
* Add manual integration tests for various go mod corner cases.
* Move integration test back and actually test the outputs.
I realize now this is run in a travis CI job :) So I'll make it actually work.
* Add _, gofmt
* Add tools build constraint.
* Stop redirecting stderr
* Use local mode to support CI.
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.
Thus if you have a (in)direct command package as a dependency
say `myhost.com/go/package/cmd/run` you can now publish this
with the following ko command
ko publish myhost.com/go/package/cmd/run
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
