* Don't set image.base.name if base is specified by digest
* don't set empty annotation
* annotate Results, not Images and Indexes separately
* moar cleanup
* skip annotations check for images in indexes, these won't be annotated anymore
* Build working Windows container images
Add e2e tests that run on Windows and cover kodata behavior
* now successfully skipping symlinks on windows :-/
* fix e2e test on windows, that relied on a symlink in kodata after all
* document windows symlink issue
* review feedback
* re-add kodata symlink tests for linux
There are use cases, where multiple Go build flags need to be set. However, the
environment variable to pass flags to Go build has some limits for `ldFlags`.
Add GoReleaser inspired configuration section to `.ko.yaml` to support setting
specific Go build and ldFlags to be used by the build. Like GoReleaser the
content of the configuration can use Go templates. Currently, only a section
for environment variables is included.
In order to reduce dependency overhead, only the respective config structs from
https://github.com/goreleaser/goreleaser/blob/master/pkg/config/config.go are
used internally to load from `.ko.yaml`.
This change adds a `WorkingDirectory` field to `options.BuildOptions`,
but doesn't expose this as a CLI flag. The default zero value means the
current working directory. The value is used as the directory for
executing `go` tool commands.
When embedding ko in other tools, it is sometimes necessary to set the
working directory for executing the `go` tool, instead of assuming the
current process working directory.
An example of where this is required from Skaffold:
https://github.com/GoogleContainerTools/skaffold/tree/master/examples/microservices
In this example, the working directory doesn't contain either `go.mod`
or any Go files. The `skaffold.yaml` configuration file specifies
a `context` field for each image, which is the directory where the `go`
tool can find package information.
* Allow comma-separated list of platforms
* Parse platform spec once
* Update --platform docs in README
* Update pkg/build/gobuild_test.go
Co-authored-by: Matt Moore <mattmoor@vmware.com>
* Return err for bad defaulting for --platform
Also respect GOARM as variant if the goarch is arm.
* Refactor platform matching
* Update README.md to mention GOARM
* Fix travis test
Co-authored-by: Matt Moore <mattmoor@vmware.com>
* Add ctx to publish.Interface
I noticed that hitting ctrl-C didn't work when pushing images, this
should fix that.
* Use context everywhere that makes sense
* 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!
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
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>
* 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
* Add support for recursively resolving directory symlinks.
This adds support for properly resolving directory symlinks within kodata.
I verified that with this I can symlink `.git/refs` into `kodata/` and (with
changes) resolve the `.git/HEAD` symlink to read the appropriate
`ref: refs/heads/...` files with the commit SHA.
* Incorporate code review feedback
