Idea: build all images defined in .ko.yaml

Idea

Running ko build --all or similar will build all builds[] defined in .ko.yaml.

Motivation

Once you have more than a few builds defined, it becomes tedious to build everything. This is particularly true in a monorepo where you may have dozens of builds to publish in a CI pipeline.

Ooh, nice. This would be useful for folks who aren't using the Kubernetes integration, to just build a whole repo's worth of images.

I wonder if we should just accept ko build ./... semantics, like go build does. This could scan the path for any package main and ko build it. This way users wouldn't have to define a builds section for each package main in their tree, which could get cumbersome if you have dozens of them.

You can use go list -json to discover packages, and jq to filter those for packages that are package main.

$ go list -json ./... | jq -r -s '.[] | select (.Name == "main") | .ImportPath'
github.com/google/ko
github.com/google/ko/cmd/help
github.com/google/ko/test

So this should ko build every suitable package in your tree:

go list -json ./... | jq -r -s '.[] | select (.Name == "main") | .ImportPath' | xargs ko build

That should work, but it's not a great UX. We could package the ~same logic into ko itself to basically just do this when you ko build ./... (or ko build ./cmd/..., or whatever)

ko build ./... is useful in some cases, however in my use case I really don't want to build and push everything, only those builds I've defined in .ko.yaml 😀

skaffold build follows a similar behaviour in that without any args it builds everything defined in skaffold.yaml.

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.

Just found ko, and after trying it in one of our repos, would very much like a --all feature that builds everything from the configuration file. In my case, at least, it would be more useful than supporting ./... (although the two do not really conflict). We tend to have a number of utility programs in our repos, so just blindly building everything with package main would be rather wasteful.

I'd be willing to give implementation a try if this would be accepted?

@carlpett that's the same as my use case. I think it's a very valid argument, ./... is just too inflexible.

As mentioned above I just use skaffold instead since it has this capability and I need to build a few non-Go containers too.

I think we should support ko build --all.

an alternative dumb (bash) approach might be:

# for each "main:" entry call ko build with params (2 in parallel)"
cat .ko.yaml | grep "main:" | cut -f 2 -d ':' | xargs -n 1 -P 2  ./bin/ko build \
                --sbom=none \
                --tags="$_image_tags" \
                --base-import-paths \
                --preserve-import-paths \
                --platform=linux/amd64,linux/arm64

whereas my .ko.yaml file looks like:

builds:
... 

- id: my_module_temporal_app
 main: ./public_module/temporal_app
 dir: .
 ldflags:
 - -extldflags "-static"
 - -X main.BuildHost={{.Env.APP_BUILD_HOST}}
 - -X main.BuildDate={{.Env.APP_BUILD_DATE}}

...
 

hi, I am also interested in this feature - mainly because I have monorepo, and in CI I can expose the path to project which I would like to build - like monorepo/some/project, however different projects have different layouts (the place where they put cmd - like cmd/sth cmd/sth-else) - so currently I do not see a way to make it with ko in generic way.

What I would expect that I point ko to the location of .ko.yaml in each of the projects and it will build all or selected id defined in the config file.

Does this sounds as a reasonable use case?