search

ko-build / ko

Build and deploy Go applications
https://ko.build
Apache License 2.0
7.55k stars 396 forks source link

Idea: Convention for vendoring `ko`-able configs #526

Closed mattmoor closed 2 years ago

mattmoor commented 2 years ago

Background

Today it is possible for ko to build binaries referenced in configurations within a module so long as those binaries' entrypoints have been added as dependencies, e.g. through _ imports like this: https://github.com/mattmoor/mink/blob/8d7a4b7ff8d9d36b59f858e6a6ac01d9aacf3103/hack/tools.go#L36-L53

Another interesting convention is to allow folks to import configs with a similar mechanism: https://github.com/mattmoor/mink/blob/8d7a4b7ff8d9d36b59f858e6a6ac01d9aacf3103/hack/tools.go#L31 which requires placing a placeholder.go file into each vendor-able config directory: https://github.com/knative-sandbox/net-kourier/blob/main/config/placeholder.go

The Idea

The big idea here is: what if placeholder.go became something like placeholder.ko.go[1] and contained _ imports for each of the referenced Go binaries?

[1] - inspired by .pb.go, but a total strawperson.

What this enables

This would enable users to just vendor a config directory, and all of the appropriate binaries would automatically get pulled in, which means I could:

ko apply -f ./vendor/github.com/knative-sandbox/net-kourier/config

... and it just works!

So what's the ask?

Folks could just do this today (I believe), but it requires forking the source of truth: the configs.

If we think this idea has legs, then I'd propose we add something like ko STEVE -Rf config that walks the configs in each directory and builds up a placeholder.ko.go file for each directory with configs.

Then folks could run similar checks to verify-codegen to ensure things WAI.

github-actions[bot] commented 2 years ago

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Keep fresh with the 'lifecycle/frozen' label.