Expand 'goos' and 'goarch' combinations in 'dockers'.

[eine]

I am trying to reproduce the compact syntax of the 'build' field in order to generate multiple docker images, each one corresponding to a built binary, and all of them based on the same Dockerfile and sharing the same image name.

Given then following configuration file, I'd like multiple docker images to be created, each of them with two tags.

project_name: filebrowser

build:
  env:
    - CGO_ENABLED=0 
  main: cmd/filebrowser/main.go
  binary: filebrowser
  goos:
    - darwin
    - linux
    - windows
    - freebsd
    - netbsd
    - openbsd
    - dragonfly
    - solaris
  goarch:
    - amd64
    - 386
    - arm
    - arm64
  goarm:
    - 5
    - 6
    - 7
  ignore:
    - goos: darwin
      goarch: 386
    - goos: openbsd
      goarch: arm
    - goos: freebsd
      goarch: arm
    - goos: netbsd
      goarch: arm
    - goos: solaris
      goarch: arm

archive:
  name_template: "{{.Os}}-{{.Arch}}{{if .Arm}}v{{.Arm}}{{end}}-{{ .ProjectName }}"
  format: tar.gz
  format_overrides:
    - goos: windows
      format: zip

release:
  disable: true

dockers:
  goos: linux
  goarch:
    - amd64
    - arm
    - arm64
  goarm:
    - 7
    - 6
  image: "{{ .ProjectName }}/{{ .ProjectName }}"
  skip_push: true
  tag_templates:
    - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-{{ .Tag }}"
    - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-latest"
  extra_files:
    - Docker.json

The problems I find are:

• Each of goarch and goarm in dockers must have a single value.
• {{ .ProjectName }} cannot be used to set the dockers image.
• Neither {{ .Arch }} nor {{ .Arm }} can be used to set tag_templates.

I've considered setting each image explicitly:

dockers:
  -
    goos: linux
    goarch: amd64
    goarm: ''
    image: filebrowser/filebrowser
    skip_push: true
    tag_templates:
      - "amd64-{{ .Tag }}"
      - "amd64-latest"
    extra_files:
      - Docker.json
  -
    goos: linux
    goarch: arm64
    goarm: 7
    image: filebrowser/filebrowser
    skip_push: true
    tag_templates:
      - "arm64v7-{{ .Tag }}"
      - "arm64v7-latest"
    extra_files:
      - Docker.json
...

As additional context, this is the Dockerfile:

FROM scratch

VOLUME /tmp
VOLUME /srv
EXPOSE 80

COPY filebrowser /filebrowser
COPY Docker.json /config.json

ENTRYPOINT ["/filebrowser", "--config", "/config.json"]

[caarlos0]

setting each image explicitly will work, but we should indeed fix those issues.

Thanks for opening this issue!

[caarlos0]

#716 will fix this two items:

• {{ .ProjectName }} cannot be used to set the dockers image.
• Neither {{ .Arch }} nor {{ .Arm }} can be used to set tag_templates.

the other one will be fixed in another PR

[caarlos0]

I was thinking, I'm not sure this is a good idea.

For example, most arm-based images will have another base image -> https://github.com/docker-library/official-images#architectures-other-than-amd64

So, maybe it will end up making all things overcomplicated... For builds, it is easy enough to guess which goos/goarch/goarm combos are valid or not, for docker I think it may not be that easy.

Maybe I'm missing something here, but it seems to be that a little repetition may be better in this case...

Thoughts?

GitHub

docker-library/official-images

official-images - Primary source of truth for the Docker "Official Images" program

[eine]

I think that expansion is mostly useful for applications distributed in scratch images, where you don't need to worry about the host system.

In other contexts, it'd be great to support partially sharing the params. For example:

dockers:
  - goarch: amd64
    from: debian:buster-slim
  - goarch: arm64
    goarm: 8
    from: arm64v8/debian:buster-slim
  - goarch: arm
    goarm: 6
    from: arm32v6/alpine
  goos: linux
  image: "{{ .ProjectName }}/{{ .ProjectName }}"
  skip_push: true
  tag_templates:
    - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-{{ .Tag }}"
    - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-latest"
  extra_files:
    - Docker.json

[caarlos0]

this second proposal seems to make more sense... you could use yaml variables though...

[eine]

this second proposal seems to make more sense... you could use yaml variables though...

That makes sense. I had not thought about yaml variables!

However, in order to support using the same Dockerfile, adding a from field would be desirable, as it would avoid the requirement to create multiple copies which are different only because of the FROM line.

dockers:
  - &docker
    goarch: amd64
    from: debian:buster-slim
    goos: linux
    image: "{{ .ProjectName }}/{{ .ProjectName }}"
    skip_push: true
    tag_templates:
      - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-{{ .Tag }}"
      - "{{ .Arch }}{{if .Arm}}v{{.Arm}}{{end}}-latest"
    extra_files:
      - Docker.json
  - <<: *docker
    goarch: arm64
    goarm: 8
    from: arm64v8/debian:buster-slim
  - <<: *docker
    goarch: arm
    goarm: 6
    from: arm32v6/alpine

[caarlos0]

this would mean templating the Dockerfile as well - which also means you won't be able to manually build from that Dockerfile anymore.

I think repeating a bit of code here makes things easier to understand and to maintain later...

[eine]

What about using FROM debian:buster-slim AS gorelease as a template? That would allow to use the Dockerfile manually.

[caarlos0]

I rather leave things the way it is for now.

This little repetition won't hurt and support all scenarios already.

The template enhancements were valid though, and they are implemented.

That being said, I'll close this for now.

[github-actions]

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