add ko support for building and pushing container images

[developer-guy]

Signed-off-by: Batuhan Apaydin batuhan.apaydin@trendyol.com
Co-authored-by: Furkan furkan.turkal@trendyol.com (@Dentrax)
Co-authored-by: Erkan Zileli erkan.zileli@trendyol.com (@erkanzileli)

fix #2556

to add ko support for building and pushing container images

Sample .goreleaser.yml

# This is an example .goreleaser.yml file with some sensible defaults.
# Make sure to check the documentation at https://goreleaser.com
before:
  hooks:
    # You may remove this if you don't use go modules.
    - go mod tidy
builds:
  - env:
      - CGO_ENABLED=0
    goos:
      - linux
      - windows
      - darwin
    ldflags:
      - -s -w -X github.com/GoTurkiye/hello-world-cli/cmd.GitCommit={{ .Commit }} -X github.com/GoTurkiye/hello-world-cli/cmd.Version={{ .Version }}
archives:
  - replacements:
      darwin: Darwin
      linux: Linux
      windows: Windows
      386: i386
      amd64: x86_64
checksum:
  name_template: 'checksums.txt'
snapshot:
  name_template: "{{ incpatch .Version }}-next"
changelog:
  sort: asc
  filters:
    exclude:
      - '^docs:'
      - '^test:'
dockers:
  - image_templates: [ "ghcr.io/goturkiye/{{ .ProjectName }}"]
    goos: linux
    goarch: amd64
    use: ko  ## notice here

[caarlos0]

thanks for the PR!

made some comments here.

would also be nice to add tests for this 🙏

[caarlos0]

btw, with this we can also easily create multi-arch docker images, just need to pass --platform=all to docker args 🤝

[caarlos0]

thinking more about this, I got more questions:

• ko has a lot of config that the docker pipe wont support... what should we do about that?
• in the same line, we are inferring the module from ./go.mod, but what happens if the user has many go.mod files?

everything would likely work for "simple" projects, but not sure about more complex ones...

[developer-guy]

I completed all the comments, here is the result when I tried this integration with my own CLI and it uses the following .goreleaser.yaml:

$ export GITHUB_TOKEN=xxx
$ export KO_DOCKER_REPO=docker.io/devopps
$ goreleaser release --rm-dist
$ crane ls devopps/hello-world-cli
0.3.3
latest
v0

.goreleaser

# This is an example .goreleaser.yml file with some sensible defaults.
# Make sure to check the documentation at https://goreleaser.com
before:
  hooks:
    # You may remove this if you don't use go modules.
    - go mod tidy

builds:
  - env:
      - CGO_ENABLED=0
    goos:
      - linux
      - windows
      - darwin
    ldflags:
      - -s -w -X github.com/GoTurkiye/hello-world-cli/cmd.GitCommit={{ .Commit }} -X github.com/GoTurkiye/hello-world-cli/cmd.Version={{ .Version }}
archives:
  - replacements:
      darwin: Darwin
      linux: Linux
      windows: Windows
      386: i386
      amd64: x86_64
checksum:
  name_template: 'checksums.txt'
snapshot:
  name_template: "{{ incpatch .Version }}-next"
changelog:
  sort: asc
  filters:
    exclude:
      - '^docs:'
      - '^test:'
dockers:
  - image_templates:
    - "{{ .ProjectName }}"
    - "{{ .ProjectName }}:{{ .Tag }}"
    - "{{ .ProjectName }}:v{{ .Major }}"
    goos: linux
    goarch: amd64
    use: ko

PTAL @caarlos0 @imjasonh @Dentrax @erkanzileli

[developer-guy]

thinking more about this, I got more questions:

• ko has a lot of config that the docker pipe wont support... what should we do about that?
• in the same line, we are inferring the module from ./go.mod, but what happens if the user has many go.mod files?

everything would likely work for "simple" projects, but not sure about more complex ones...

@imjasonh maybe can help us here.

[imjasonh]

Sorry for the delayed response.

I'm a bit worried that ko-in-goreleaser will be confusing since ko itself reuses some of goreleaser's config types in .ko.yaml, and it may be confusing to decide where to describe certain things between goreleaser (how the binary gets built) and .ko.yaml (how the image(s) get built)

For the question of "how to configure ko", could we have a special ko: section in the goreleaser config? This would let users describe their module without having to inspect go.mod(s), and could also help with unsupported fields in the docker: field, since we won't need to use it.

wdyt?

cc @jonjohnsonjr

[developer-guy]

Sorry for the delayed response.

I'm a bit worried that ko-in-goreleaser will be confusing since ko itself reuses some of goreleaser's config types in .ko.yaml, and it may be confusing to decide where to describe certain things between goreleaser (how the binary gets built) and .ko.yaml (how the image(s) get built)

For the question of "how to configure ko", could we have a special ko: section in the goreleaser config? This would let users describe their module without having to inspect go.mod(s), and could also help with unsupported fields in the docker: field, since we won't need to use it.

wdyt?

cc @jonjohnsonjr

thank you for such a great explanation, I think both methods (current solution and your suggestion) would work fine but yes I agree with your concerns about configuring ko while using it in GoReleaser because ko also builds the binary first which means that fields defined in build: section will be ignored in this case, so we have to use something like the following (moving the build section to .ko.yaml)

👀 https://github.com/google/ko#overriding-go-build-settings

WDYT @caarlos0?

[caarlos0]

I'm thinking maybe we could instead use ko as a dependency and skip the go build part (as we already do that), and just build the images... would that be possible (haven't investigate ko's codebase yet)? if so, wdyt?

[Dentrax]

I'm thinking maybe we could instead use ko as a dependency and skip the go build part (as we already do that), and just build the images... would that be possible (haven't investigate ko's codebase yet)? if so, wdyt?

I'm not so sure whether instead of using the binary, and importing ko code as a library is an anti-pattern or not. Is ko intended to be used as a library? We can use it as a library ofc, but that is a side-effect of how ko code is structured, which is subject to change. To clarify aforementioned concerns and the getting feedback from "ko as a dependency", cc'ing @imjasonh 🙃

[imjasonh]

ko can be used as a library, some folks on Skaffold are also looking into integrating ko using its library methods.

The main functions you'd probably care about are build.NewGo to create a new builder, and publish.NewDefault to push the image.

[caarlos0]

cc/ @cpanato

[caarlos0]

closing for now, as we'll discuss this in our community meeting

[jonjohnsonjr]

@caarlos0 tried searching briefly for docs around a community meeting and couldn't find anything -- have a link handy?

[caarlos0]

sure, here you go: goreleaser/community#2

PS: we don't have a proper date yet, but likely later january or early february

[developer-guy]

let's kick this off and rewrite it by using ko as a library instead of executing it directly through the binary.

This repo will help us with that: https://github.com/imjasonh/miniko.

/cc @imjasonh @caarlos0

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.