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
* Create a MultiPublisher
MultiPublisher mimics io.MultiWriter in that it will publish an image to
multiple publish.Interface implementations.
* Add publish.{Tarball,Layout}Publisher
This adds support for publishing in the tarball format and to an OCI
image layout.
The tarball format isn't great, yet. It only supports writing once
instead of appending.
* Consolidate options
These were spread all over the place for no reasons. Now all the
publisher related options are grouped together.
* Add options for tarball/layout
Adds --oci-layout-path, --tarball, and --push flags.
--push=false will disable the default behavior of publishing to a
registry.
* go mod vendor
* Add Close method to publish.Interface
This allows us to defer writing to the tarball until we've collected all
the images that have been published.
* Fix tests
When resolving files, we would just log.Fatal if we encountered an
error. This seems to be racy and causes ko to exit with a 0 error code
when it shouldn't. To fix this, we synchronize the builder goroutines
with the kubectl go routine and exit with an error if either of them
failed.
This fix also happened to fix a goroutine leak. If the kubectl goroutine
failed, we never properly cancelled the builds, which would happily
conitnue compiling packages and consuming resources.
Fixes the PATH environment variable so it contains the directory
containing the binary (i.e., /ko-app) instead of the binary itself
(e.g., /ko-app/ko).
See #114.
