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.
Since we are always building linux containers, use `path.Join` rather than
`filepath.Join` when adding files to the tar.
Signed-off-by: Evan Anderson <evan.k.anderson@gmail.com>
If a single tag is explicitly set (i.e. it's not "latest"), include that
in the reference that gets rendered in the yaml.
This is really useful for tracking releases.
* Preserve YAML comments & style when resolving/applying
This is accomplished by adopting the yaml.v3 lib. It
exposes a Node struct that's used internally by the
yaml encoder/decoder
ko internally now manipulates YAML documents using this struct
Fixes#101
* add/remove vendored modules
* Apply suggestions from code review
Fix comments
Co-Authored-By: jonjohnsonjr <jonjohnson@google.com>
* update doc link
* Fix use of yaml.Decoder in a test
When the yaml.Decoder returns an io.EOF it implies
there were no YAML documents decoded and that there
are no more!
* Update pkg/resolve/resolve.go
resolve comment suggestion
Co-Authored-By: jonjohnsonjr <jonjohnson@google.com>
* leave ko prefix if we're not operating in strict mode
* move testutils to internal/testing
* Add trimpath arg to gobuild
* Add build constraints for trimpath usage
* Reduce duplications across go versions
* Change trimpath fn-files for better names
* Attempt to apply with minikube on Travis
* Attempt to apply with KinD on Travis
* Install kind thru curl to not affect build
* Use debug.ReadBuildInfo to populate `ko version`
* don't print version on build info failure
* Build using Go 1.12 and 1.13
* drop 'version: ' prefix
* println
* Add build.Limiter
You can limit the number of concurrent builds with -j (a la make).
The default value for this is GOMAXPROCS, which seems reasonable.
