DRY up GoReleaser config for publishing Docker images?

[polarathene]

Recently I've seen two popular projects manage Docker image publishing through GoReleaser, but compared to the equivalent in Github Actions it doesn't seem very DRY?:

• ci: build artifacts with GoReleaser and use Release Please editorconfig-checker/editorconfig-checker#385 (comment)
• https://github.com/ory/xgoreleaser/blob/a5d1b76dc608ec08aa9df19b7f12c0f32b0471a9/build.tmpl.yml#L396-L579

I'm not that familiar with GoReleaser, but had a quick look through the docs and searching issues/discussions and I didn't notice anything that addressed that concern of how repetitive that config was with GoReleaser.

Are the reference configs just not taking advantage of a feature, or would GoReleaser need to implement some functionality to allow simplifying that?

[caarlos0]

Yes, I get that it is pretty repetitive and error prone.

I have plans to do a dockers_v2 kind of thing that handles it all, just haven't got to do it yet.

I was kinda hoping they would fix docker/cli#3350 , but seems like it won't happen, so I might as well just go around it anyway 🤔

[caarlos0]

FWIW my idea would be for something like this:

alpha_dockers:
  - image_templates:
      - "goreleaser/goreleaser:v{{ .Version }}"
      - "{{ if not .IsNightly }}goreleaser/goreleaser:latest{{ end }}"
      - "{{ if .IsNightly }}goreleaser/goreleaser:nightly{{ end }}"
      - "ghcr.io/goreleaser/goreleaser:v{{ .Version }}"
      - "{{ if not .IsNightly }}ghcr.io/goreleaser/goreleaser:latest{{ end }}"
      - "{{ if .IsNightly }}ghcr.io/goreleaser/goreleaser:nightly{{ end }}"
    dockerfile: Dockerfile
    use: buildx
    platforms:
      - linux/amd64
      - linux/arm64
    build_flag_templates:
      - "--pull"
      - "--label=io.artifacthub.package.readme-url=https://raw.githubusercontent.com/goreleaser/goreleaser/main/README.md"
      - "--label=io.artifacthub.package.logo-url=https://goreleaser.com/static/avatar.png"
      - '--label=io.artifacthub.package.maintainers=[{"name":"Carlos Alexandro Becker","email":"[email protected]"}]'
      - "--label=io.artifacthub.package.license=MIT"
      - "--label=org.opencontainers.image.description=Release engineering, simplified"
      - "--label=org.opencontainers.image.created={{.Date}}"
      - "--label=org.opencontainers.image.name={{.ProjectName}}"
      - "--label=org.opencontainers.image.revision={{.FullCommit}}"
      - "--label=org.opencontainers.image.version={{.Version}}"
      - "--label=org.opencontainers.image.source={{.GitURL}}"
      - "--platform={{ .Platform }}"
    extra_files:
      - scripts/entrypoint.sh

[polarathene]

but seems like it won't happen

IIRC the containerd image store might resolve that, but it's still considered experimental (opt-in) and I have no clue if that gets impacted by upcoming Docker v28 which updates containerd to 2.0 release.

I haven't had time to play around with that yet, but AFAIK containerd image store would support multi-platform images / manifest. Presently you can use the buildx docker-container driver for multi-platform builds, but the current local image store will only support one platform per image at a time.

---

FWIW my idea would be for something like this:

I mean that looks like an improvement for sure, but if you can better match the GHA config it'd probably be a much nicer DX?:

alpha_dockers:
  - dockerfile: Dockerfile
    use: buildx
    platforms:
      - linux/amd64
      - linux/arm64
    build_flag_templates:
      - "--pull"
    extra_files:
      - scripts/entrypoint.sh
    with_metadata:
      images: |
        docker.io/goreleaser/goreleaser
        ghcr.io/goreleaser/goreleaser
      tags: |
        type=raw,value=nightly,enabled={ .IsNightly }
        type=semver,pattern=v{ .Major }
        type=semver,pattern=v{ .Major }.{ .Minor }
        type=semver,pattern=v{ .Major }.{ .Minor }.{ .Patch }
      labels: |
        io.artifacthub.package.readme-url=https://raw.githubusercontent.com/goreleaser/goreleaser/main/README.md
        io.artifacthub.package.maintainers=[{"name":"Carlos Alexandro Becker","email":"[email protected]"}]
        io.artifacthub.package.license=MIT
        org.opencontainers.image.created={{.Date}}
        org.opencontainers.image.name={{.ProjectName}}
        org.opencontainers.image.revision={{.FullCommit}}
        org.opencontainers.image.version={{.Version}}
        org.opencontainers.image.source={{.GitURL}}

NOTE:

• Looking over the GoReleaser Docker docs dockerfile and use fields are presumably not necessary, even with the implicit default use: docker, I think that will default to buildx since v23 of Docker?
• For images:
  • docker.io/ is technically implicit and can be omitted.
  • While this example the only difference is in registry, I have seen projects where their DockerHub vs GHCR repo name differs.
• For tags:
  • docker/metadata-action has type=edge,branch=master as a convenience type (that is git aware) for builds representing the latest commit, while a "nightly" style build might be better suited with type=schedule,pattern=nightly, but that's relying on CI integration (type=raw,value=my-tag is for when you want to provide your own tag explicitly).
  • There are also attributes where you could append ,enable={ .IsNightly } to the end of a declared tag to toggle it based on a boolean value, like this: type=raw,value=nightly,enabled={ .IsNightly } (EDIT: Updated the example to use this instead of type=edge).
  • Rather than repeat the same logic for each tag per registry, since images + tags are separate fields you should be DRY with this approach. That enable attribute for a tag would allow additional control if it can check the context of a registry for the tag validity. In GHA another pattern is to define more than one docker/metadata-action step when your metadata diverges enough (the later docker/build-push-action step(s) can then select the appropriate metadata source).
  • The type=semver reads the git tag (in GHA this only used when the event type is a git tag push) and if it's semver compatible you can use the semver components, just like GoReleaser seems to support.
  • I've got 3 semver tags here as a common convention is to have major + major.minor tags as well for tooling that monitors updates to the tag (points to an updated image digest at the registry), Watchtower does this for example, I think Podman has similar built-in for auto-updates, neither are technically doing so via semver, but these additional tag variants enable that functionality.
• For labels:
  • Pretty self-explanatory, instead of the extra noise of additional build args as an array, you have like the other fields prior to it, a multi-line YAML string where each line is an individual input. I personally find that cleaner to read.
  • There's a very similar annotations field (difference covered here). It'd use the same logic as labels to convert each line into the equivalent --annotation key/value arg to append.

"--platform={{ .Platform }}" seems redundant if you have platforms field setting those? FWIW you should be able to provide a list of all platforms to that arg and it'll build for each one.

Another option is to defer to [Docker Bake](https://docs.docker.com/build/bake/reference/) and use it's bake file. docker/metadata-actionjust focuses on the metadata portion separately and can be paired withdocker/build-push-action or [docker/bake-actionwith a bake file output](https://github.com/docker/metadata-action?tab=readme-ov-file#bake-definition) that's JSON paired with a separatedocker-bake.hcland feed intodocker buildx bake ...`. That has a benefit of encoding most of the build, but leaving some of it external for CI to handle such as image tags and labels only relevant to publishing releases with.

I totally understand if you'd prefer avoiding the multi-line string approach for consistency and ease of parsing, only real difference is a - prefix to switch those to list items :)

[ryancurrah]

From that Docker issue creating manifests.

You can do what the manifest command does in multiple stages. We do this after running go releaser.

# Create the multi-arch manifest
docker manifest create myusername/myimage:multi-arch \
    myusername/myimage:amd64 \
    myusername/myimage:arm64

# Annotate the manifest
docker manifest annotate myusername/myimage:multi-arch myusername/myimage:amd64 --arch amd64
docker manifest annotate myusername/myimage:multi-arch myusername/myimage:arm64 --arch arm64

# Push the multi-arch manifest
docker manifest push myusername/myimage:multi-arch

[caarlos0]

@ryancurrah yes, but the images needs to be pushed... if you do magic docker build manifest command directly, it won't need intermediary docker images.

[caarlos0]

@polarathene yes the labels and tags splits are probably a good idea.

I won't focus on copying directly the action, but we can for sure copy some things from it

Something like:

alpha_dockers:
  - images:
      - "goreleaser/goreleaser"
      - "ghcr.io/goreleaser/goreleaser"
    tags:
      - "v{{ .Version }}"
      - "{{ if not .IsNightly }}latest{{ end }}"
      - "{{ if .IsNightly }}nightly{{ end }}"
    dockerfile: Dockerfile # default
    use: buildx # default
    platforms:
      - linux/amd64
      - linux/arm64
    labels:
      io.artifacthub.package.readme-url: "https://raw.githubusercontent.com/goreleaser/goreleaser/main/README.md"
      io.artifacthub.package.logo-url: "https://goreleaser.com/static/avatar.png"
      io.artifacthub.package.maintainers: '[{"name":"Carlos Alexandro Becker","email":"[email protected]"}]'
      io.artifacthub.package.license: "MIT"
      org.opencontainers.image.description: "Release engineering, simplified"
      org.opencontainers.image.created: "{{.Date}}"
      org.opencontainers.image.name: "{{.ProjectName}}"
      org.opencontainers.image.revision: "{{.FullCommit}}"
      org.opencontainers.image.version: "{{.Version}}"
      org.opencontainers.image.source: "{{.GitURL}}"
    build_flag_templates:
      - "--pull" 
    extra_files:
      - scripts/entrypoint.sh