Idea: build all images defined in .ko.yaml

[jsok]

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.

[imjasonh]

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.

[imjasonh]

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)

[jsok]

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.

[github-actions]

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.

[carlpett]

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?

[jsok]

@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.

[imjasonh]

I think we should support ko build --all.

[cernoel]

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}}

...
 

[grzesuav]

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?