cannot output arch linux image to local directory

[ReenigneArcher]

Contributing guidelines

• I've read the contributing guidelines and wholeheartedly agree

I've found a bug, and:

• The documentation does not mention anything about my problem
• There are no open or closed issues that are related to my problem

Description

Since today, I cannot output the built image to a local directory. This worked yesterday, so I'm not quite sure what is causing the problem.

I use the outputs option to copy the built images to the local runner as a way to copy the release assets out of the image.

      - name: Build and push
        id: build
        uses: docker/build-push-action@v6
        with:
          context: ./
          file: ${{ matrix.dockerfile }}
          push: ${{ inputs.publish_release }}
          platforms: ${{ steps.prepare.outputs.platforms }}
          build-args: |
            BRANCH=${{ steps.prepare.outputs.branch }}
            BUILD_DATE=${{ steps.prepare.outputs.build_date }}
            BUILD_VERSION=${{ inputs.release_version }}
            COMMIT=${{ inputs.release_commit }}
            CLONE_URL=${{ steps.prepare.outputs.clone_url }}
            RELEASE=${{ inputs.publish_release }}
          tags: ${{ steps.prepare.outputs.tags }}
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache
          outputs: 'type=local,dest=image'

Expected behaviour

Copy image files out of built image as it did before.

Actual behaviour

Cannot copy files out of image, permission denied.

Repository URL

https://github.com/LizardByte/Sunshine

Workflow run URL

https://github.com/LizardByte/Sunshine/actions/runs/16061306236/job/45329065378#step:10:3681

YAML workflow

https://github.com/LizardByte/.github/blob/master/.github/workflows/__call-docker.yml called from https://github.com/LizardByte/Sunshine/blob/2259141bd2493eb1b88e74469e0784fcef06a3e0/.github/workflows/ci.yml#L56

Workflow logs

#33 [sunshine 6/6] WORKDIR /home/lizard
#33 DONE 0.0s

#34 exporting to client directory
#34 copying files
#34 copying files 3.36MB 0.0s done
#34 ERROR: error from receiver: failed to symlink image/etc/ca-certificates/extracted/cadir/002c0b4f.0: symlink GlobalSign_Root_R46.pem image/etc/ca-certificates/extracted/cadir/002c0b4f.0: permission denied
------
 > exporting to client directory:
------
ERROR: failed to build: failed to solve: error from receiver: failed to symlink image/etc/ca-certificates/extracted/cadir/002c0b4f.0: symlink GlobalSign_Root_R46.pem image/etc/ca-certificates/extracted/cadir/002c0b4f.0: permission denied

BuildKit logs

Additional info

Dockerfile: https://github.com/LizardByte/Sunshine/blob/master/docker/archlinux.dockerfile

I just started extracting the full image using outputs a few days ago, but it definitely worked. I am not sure if this failure is due to some weird change in the arch linux base image or what. Any guidance/solution would be appreciated. I'd be happy to provide any more details if necessary.

[crazy-max]

as a way to copy the release assets out of the image.
...
I just started extracting the full image using outputs a few days ago

You should not output the full rootfs if you just want your built binaries. In such case you should have a scratch stage that just copies what you need as shown in https://docs.docker.com/build/building/export/#export-binaries-from-a-build

In your Dockerfile right before the last sunshine stage https://github.com/LizardByte/Sunshine/blob/2259141bd2493eb1b88e74469e0784fcef06a3e0/docker/archlinux.dockerfile#L115 you would have a stage named artifacts with only the artifacts like:

...
FROM scratch AS artifacts
COPY --link --from=sunshine-build /build/sunshine/pkg/sunshine*.pkg.tar.zst /sunshine.pkg.tar.zst
COPY --link --from=sunshine-build /build/sunshine/sunshine.pkg.tar.gz /sunshine.pkg.tar.gz

FROM sunshine-base AS sunshine
...

You can then remove https://github.com/LizardByte/Sunshine/blob/2259141bd2493eb1b88e74469e0784fcef06a3e0/docker/archlinux.dockerfile#L119-L121 that are not used in your runnable image

Then in the build step: https://github.com/LizardByte/.github/blob/9e4ccf81b58554cd7a4a2167e49cae94627b6121/.github/workflows/__call-docker.yml#L264-L283

You should set target input to artifacts depending of what you want to build and I guess in this case it would be:

      - name: Build and push
        id: build
        uses: docker/build-push-action@v6
        with:
          context: ./
          file: ${{ matrix.dockerfile }}
          push: ${{ inputs.publish_release }}
          platforms: ${{ steps.prepare.outputs.platforms }}
          build-args: |
            BRANCH=${{ steps.prepare.outputs.branch }}
            BUILD_DATE=${{ steps.prepare.outputs.build_date }}
            BUILD_VERSION=${{ inputs.release_version }}
            COMMIT=${{ inputs.release_commit }}
            CLONE_URL=${{ steps.prepare.outputs.clone_url }}
            RELEASE=${{ inputs.publish_release }}
          tags: ${{ steps.prepare.outputs.tags }}
          cache-from: type=local,src=/tmp/.buildx-cache
          cache-to: type=local,dest=/tmp/.buildx-cache
          no-cache-filters: ${{ steps.prepare.outputs.no_cache_filters }}
          outputs: ${{ steps.prepare.outputs.artifacts == 'true' && './artifacts' || '' }}
          target: ${{ steps.prepare.outputs.artifacts == 'true' && 'artifacts' || '' }}

Then you can remove the next step "Arrange Artifacts": https://github.com/LizardByte/.github/blob/9e4ccf81b58554cd7a4a2167e49cae94627b6121/.github/workflows/__call-docker.yml#L285-L306

And just list the artifacts:

      - name: List artifacts
        run: |
          tree -nh ./artifacts

[crazy-max]

Also looking at your Dockerfiles https://github.com/LizardByte/Sunshine/tree/master/docker and workflows I would suggest to take a look at Bake: https://docs.docker.com/build/bake/

Btw I'm a user of sunshine myself and I would be happy to contribute 🤗

[ReenigneArcher]

You should not output the full rootfs if you just want your built binaries. In such case you should have a scratch stage that just copies what you need as shown in https://docs.docker.com/build/building/export/#export-binaries-from-a-build

In your Dockerfile right before the last sunshine stage https://github.com/LizardByte/Sunshine/blob/2259141bd2493eb1b88e74469e0784fcef06a3e0/docker/archlinux.dockerfile#L115 you would have a stage named artifacts with only the artifacts like:

I did that before but it build the images twice (very rarely would it resume where it left off). This caused mutliarch builds to take 5 hours, now they are 2.5 hours. It has been bugging me for a long time and I literally just fixed that a few days ago in LizardByte/.github#475 ... 😆

The arrange artifacts is still necessary due to how they are output when doing a multiarch image. It would be nice if we could just specify the exact files/directories that we want to pull out of the image instead of extracting out the full image (whatever stage it's at).

Btw I'm a user of sunshine myself and I would be happy to contribute 🤗

That would be awesome! I'm definitely not an expert on Docker and we could use all the help we can get. Our workflow is a bit complicated as I wanted to reduce duplicated workflows among our various repos and currently the callled docker workflow works pretty well throughout our org. I haven't heard of "bake" but it seems interesting. Part of the complexity is we have different build requirements for PRs versus push events, as we don't PR builds to take so long.

[ReenigneArcher]

The problem seems to have resolved itself

[ReenigneArcher]

It seems the problem is not solved, but actually intermittent. Not sure why I only ever see this with an Arch Linux image.

[ReenigneArcher]

Starting in the past 24 hours or so, I'm hitting this 100% of the time, though the output is slightly different.

#33 exporting to client directory
#33 ERROR: open /tmp/buildkit-mount1586272105/etc/pacman.d/gnupg/S.gpg-agent: no such device or address
------
 > exporting to client directory:
------
WARNING: local cache import at /tmp/.buildx-cache not found due to err: could not read /tmp/.buildx-cache/index.json: open /tmp/.buildx-cache/index.json: no such file or directory
ERROR: failed to build: failed to solve: open /tmp/buildkit-mount1586272105/etc/pacman.d/gnupg/S.gpg-agent: no such device or address

Still only affects the Arch Linux image.

[polarathene]

I did that before but it build the images twice (very rarely would it resume where it left off). This caused mutliarch builds to take 5 hours, now they are 2.5 hours

Your CI setup is a bit too verbose for me to glance over it properly, but I roughly looked over the docker/ subdir and related ci.yml workflow that calls your docker action at another repo of yours.

You've added a bunch of additional complexity (some which could presumably be simplified a fair bit), but images shouldn't build twice just to produce a separate stage, so long as the cache is available.

The workflow advised here basically boils down to:

FROM base-image AS builder
# .. Do whatever you like

FROM scratch AS artifacts
# `COPY --from=builder` like shown earlier

FROM builder AS runtime
# Anything specific to your final runtime image

In your case builder is sunshine-base and runtime is sunshine.

The first build for either the artifacts or runtime stages would cache builder. You have the your docker action cache locally with type=local, so running another build-push-action directly after that for artifacts should have a cache to share from the filesystem. I'm not sure how you were approaching it.

EDIT: Actually, if your prior attempt was to use separate runners in parallel (one for the image build to publish and a separate for the artifacts local export), these would both take as long to build if the artifacts build doesn't wait/depend on the runtime image build for sharing the builder stage.

My approach for managing image builds

For a project I maintain, my build workflows are much simpler, I use re-usable workflows like these:

• generic_build.yml
• generic_publish.yml
• generic_test.yml

They're much simpler to look over and grok right? Those are also using the type=local cache, so should be easier for you adopt something similar.

Those generic re-usable workflows for docker builds are then called by workflows with event triggers:

• push event (build (AMD64) => test => publish (AMD64 + ARM64))
• schedule event (build => scan for vulnerabilities => publish)
• pull request event (build (AMD64) => test => build (ARM64))

We only run tests on the AMD64 build as you can see from above, as we generally place faith that ARM64 will have the same test suite results, such that we are only concerned if ARM64 image can be built successfully. Since all pushes to our main branch are via PRs, the pull request event ensures ARM64 images are successful at building and we avoid wasting time verifying that if the test suite failed.

With that setup and our tests suite being distributed across multiple runners, we brought down hour long build times down to 5 minutes for PRs with the AMD64 image build (leveraging cache) and test suite completion (the ARM64 build takes a bit longer but less of a concern).

I don't have the functionality setup there that you want with a separate stage for exporting, but you can see how our tests are dependent upon the image being built before we can run them (on separate runners that leverage that cache to rebuild the image locally quickly since we only did a build for cache without publish). And with the publish workflow, likewise the AMD64 image is already built so we reuse that local cache.

Your images RUN that handles the source build could also consider using cache mounts instead of the caveat from layer invalidation (assuming bulk of build time comes from this part), I don't have a reference to direct you to for this, but there's a separate action needed for persisting cache mount data in Github Actions. You might want to explore that if you want to bring down build times paired with ccache?

---

Alternatives docker cp or follow-up Dockerfile

An alternative to the separate artifacts stage would also be to just run the container after the image is built with docker run --rm -itd --name example my-image (may need to change the entrypoint, you just want the container to be running long enough for the next step) and then use docker cp example:/artifacts ./artifacts which will copy the container path contents to the host path. I don't think there's a separate command for that to copy from an image directly, only a running container.

Another option is a very simple separate Dockerfile:

ARG IMAGE=image-name:here
FROM ${IMAGE} as source

FROM scratch
COPY --from=source /artifacts /artifacts

You may need to avoid the push (basically repeat the build-push-action step twice, one with load: true and the next with push), or similar to how the example I showed with separate build/publish workflows. I can't recall if you can do both of those together with build-push-action, if you can then that keeps it simpler. You would then have one more build-push-action just for that small Dockerfile above without push: true that uses the output to export locally

That definitely shouldn't incur another full build of the larger image.

[polarathene]

I've run out of time to allocate further for this, so there may be some mistakes below but it should be a helpful resource if you want to consider it.

There is also a related action to compliment docker/bake-action if you'd like to have a matrix derived (an example).

Docker Bake

You were also suggested to consider using bake. Docker Bake has a separate docker-bake.hcl file, that can simplify this further with targets. You would be using bake-action instead of build-push-action.

# The `default` target name is used if no explicit bake target is given to bake.
# NOTE: Just like with `docker build`, these two are technically redundant (implicit defaults):
# - `dockerfile = "Dockerfile"`
# - `target = "runtime"` (the final stage of a Dockerfile is the default target)
target "default" {
  dockerfile = "Dockerfile"
  target = "runtime"
  # Add any other args that you'd give `docker build` here
}

# A separate bake target doesn't incur the overhead of the shared stages between Dockerfile targets of the same Dockerfile:
target "artifacts" {
  # Optionally use the same configuration as the `sunshine` target (DRY):
  inherits = ["default"]
  # Override inherited target fields as appropriate:
  target = "artifacts"
  output = ["type=local,dest=./artifacts"]
}

Alternatively, if you want to avoid introducing a separate artifacts stage, you could also approach it like this:

group "default" {
  targets = ["sunshine", "artifacts"]
}

target "sunshine" {
  dockerfile = "Dockerfile"
  target = "runtime"
}

# This target is only used to to support the `artifacts` target
# Docker Bake will only build the `builder` stage once for both `sunshine` + `sunshine-builder` targets
target "sunshine-builder" {
  inherits = ["sunshine"]
  target = "builder"

  # We're only interested in cache of this target as output:
  output = ["type=cacheonly"]
}

# An inline Dockerfile instead of requiring each Dockerfile to have an `artifacts` stage:
target "artifacts" {
  # Use the `sunshine-builder` build cache within another Dockerfile:
  contexts = {
    builder = "target:sunshine-builder"
  }

  # Use a HereDoc string to inline a basic Dockerfile (no need for a separate file):
  dockerfile-inline = <<-HEREDOC
    FROM scratch
    COPY --link --from=builder /build/sunshine/pkg/sunshine*.pkg.tar.zst /sunshine.pkg.tar.zst
    COPY --link --from=builder /build/sunshine/sunshine.pkg.tar.gz /
  HEREDOC

  # Export the image contents to the `./artifacts` directory on the host filesystem:
  # (An `--output` that is just a path is equivalent to `--output type=local,dest=./artifacts`)
  # https://docs.docker.com/build/building/export/#export-binaries-from-a-build
  # https://docs.docker.com/reference/cli/docker/buildx/build/#output
  output = ["./artifacts"]
}

Handling build args

For build args with docker/bake-action and Docker Bake, to pass in dynamic values like you would with build-args in docker/build-push-action, you would either declare variable blocks that read environment variables with the same name, or you can use --set my-target.args.my-arg=value (which is slightly more verbose).

For example with this docker-bake.hcl:

variable "SOME_VAR" {}
# You can also set a default fallback:
variable "SOME_CONDITION" { default = true }

target "example-target" {
  # `$$` is needed here to escape `$` so Bake doesn't interpolate the args as vars:
  dockerfile-inline = <<-HEREDOC
    FROM alpine
    ARG some_var conditional
    RUN echo "'$${some_var}' and '$${conditional}'"
  HEREDOC

  # The `args` field represents the `--build-arg` that get added to the image build:
  # (So without a `SOME_CONDITION` ENV set we get `--build-arg conditional=true`)
  args = {
    some_var = SOME_VAR,
    conditional = SOME_CONDITION,
  }
}

Then in docker/bake-action you'd configure:

• Via env (matching the variable names):

  - uses: docker/bake-action@v6
    env:
      SOME_VAR: hello
      SOME_CONDITION: false

• Via with.set (matching the <target>.args keys):

  - uses: docker/bake-action@v6
    with:
      set: |
        example-target.args.some_var=hello
        example-target.args.conditional=false

  set is useful with it's target pattern matching if you need to override some target fields for multiple targets, or if you want to append some extra values rather than replace the original value.

• Via a Bake config file override, such as docker-bake.override.hcl (or other supported formats like JSON which docker/metadata-action generates), or additional Bake config files that you provide explicitly to Bake.

  Your override to set args might look like:

  target "example-target" {
    args = {
      some_var = "hello"
      conditional = false
    }
  }

  This approach can be useful if you generate it via a template or jq and the like if you don't like the other methods 👍

  NOTE: There is however a known bug with file overrides where if you try to reference target fields via the special target.<target name>.<field name> syntax it fails.

---

Adapting to Github Actions

Now adapt that for use with Github Actions with docker/metadata-action and docker/bake-action:

group "default" {
  targets = ["sunshine", "artifacts"]
}

+target "docker-metadata-action" {}

target "sunshine" {
+  inherits = ["docker-metadata-action"]
  dockerfile = "Dockerfile"
  target = "runtime"
}

EDIT: I've since realized that it's better to have the sunshine target inherit sunshine-builder instead, as that's more convenient for docker/bake-action with set options.

target "docker-metadata-action" {}

group "default" {
  targets = ["sunshine", "artifacts"]
}

# Optional (_see `env` usage in the `docker/bake-action` at the end of the workflow example_)
#variable "DOCKERFILE" = { default = "Dockerfile" }

# The `sunshine` target was split out to a builder target only to support the `artifacts` target.
# (Docker Bake will only build the `sunshine-build` stage once per image build across common targets)
target "sunshine-builder" {
  dockerfile = DOCKERFILE
  target = "sunshine-build"

  # We're only interested in cache of this target as output:
  output = ["type=cacheonly"]
}

target "sunshine" {
  inherits = ["sunshine-builder", "docker-metadata-action"]
  # Optionally set a stage target to build:
  #target = "runtime"

  # Use `null` to keep the inherited value of this field (as if you didn't set it here),
  # `null` is useful with more advanced usage such as a conditional (`LOAD_IMAGE ? `type=docker` : null`).
  # Use an empty type value (`""` / `[]`) to unset the inherited field back to the default value:
  output = []
}

# An inline Dockerfile instead of requiring each Dockerfile to have an `artifacts` stage:
target "artifacts" {
  # Use the `sunshine-builder` build cache within another Dockerfile:
  contexts = {
    builder = "target:sunshine-builder"
  }

  # Use a HereDoc string to inline a basic Dockerfile (no need for a separate file):
  dockerfile-inline = <<-HEREDOC
    FROM scratch
    COPY --link --from=builder /build/sunshine/pkg/sunshine*.pkg.tar.zst /sunshine.pkg.tar.zst
    COPY --link --from=builder /build/sunshine/sunshine.pkg.tar.gz /
  HEREDOC

  # Export the image contents to the `./artifacts` directory on the host filesystem:
  # (An `--output` that is just a path is equivalent to `--output type=local,dest=./artifacts`)
  # https://docs.docker.com/build/building/export/#export-binaries-from-a-build
  # https://docs.docker.com/reference/cli/docker/buildx/build/#output
  output = ["./artifacts"]
}

As mentioned earlier, you can use additional config files to override existing targets, not just merge new targets into a unified Bake config. If you want to avoid the CI usage of supporting docker-metadata-action target, you can change this target to one that matches your docker-bake.hcl already (via the bake-target input), but be mindful of how some target fields will be completely replaced (inverse issue from using inherits).

Here is an example workflow that is roughly adapted to your existing workflow for reference:

jobs:
  docker:
    runs-on: ubuntu-latest
    steps:

      # ...

      # These three ENV aren't really needed in your actual `prepare` step,
      # you could leverage GHA expressions instead like shown here:
      # https://github.com/LizardByte/.github/blob/5189a41761ef8de8812a89c5a6ad120b5e777e63/.github/workflows/__call-docker.yml#L149-L163
      - name: Prepare
        id: prepare
        env:
          # NOTE: The `env.BRANCH` logic in your `prepare` step script (for adding `latest` + `master` tags)
          # is only valid when it is `github.ref` (not via a push event or with the fallback 'master').
          #
          # GHA expression: Use `github.ref` (if undefined, fallback to 'master'),
          # unless this is a push event (then use `github.ref_name`)
          BRANCH: ${{ github.event_name == 'push' && github.ref_name || ${{ github.ref }} || 'master' }}
          COMMIT: ${{ inputs.release_commit || github.sha }}}
          NEW_TAG: ${{ inputs.release_tag }}
        shell: bash
        run: |
          {
            echo "branch=${BRANCH}";
            echo "commit=${COMMIT}";
            echo "release_tag=${NEW_TAG}";
          } >> "${GITHUB_OUTPUT}"

      - name: 'Prepare image metadata'
        id: image-metadata
        uses: docker/metadata-action@v5
        # These could all probably be dropped in your case for the actions "Global expressions":
        # https://github.com/docker/metadata-action/blob/v5.9.0/README.md#global-expressions
        env:
          GIT_COMMIT: ${{ steps.prepare.outputs.commit }}
          RELEASE_VERSION: ${{ steps.prepare.outputs.release_tag }}
          IS_MASTER_BRANCH: ${{ steps.prepare.outputs.branch == format('refs/heads/{0}', 'master') }}
        with:
          # Images names will be their GH repository (`${{ github.repository }}` aka `<owner>/<name>`)
          # and push to the DockerHub and Github image registries.
          # This action will implicitly ensure the image names provided here are converted to lowercase:
          # https://github.com/docker/metadata-action/blob/v5.9.0/README.md#image-name-and-tag-sanitization
          images: |
            docker.io/${{ github.repository }}
            ghcr.io/${{ github.repository }}
          # Avoid implicit `latest` logic, manually control adding the `latest` as a raw tag instead:
          # https://github.com/docker/metadata-action/issues/461#issuecomment-2686558629
          flavor: |
            latest=false
            suffix=${{ matrix.tag }}
          # You may want to consider adding `priority` where appropriate:
          # https://github.com/docker/metadata-action/blob/v5.9.0/README.md#priority-attribute
          tags: |
            # - `format=short` is optional as this is the implicit default:
            #   https://github.com/docker/metadata-action#typesha
            # - NOTE: You could probably use `value={{ sha }}` here instead?:
            #   https://github.com/docker/metadata-action/blob/master/README.md#sha
            #   For PRs needing head SHA for `{{ sha }}` use the `DOCKER_METADATA_PR_HEAD_SHA` ENV:
            #   https://github.com/docker/metadata-action/blob/v5.9.0/README.md#environment-variables
            type=sha,format=short,value=${{ env.GIT_COMMIT }}

            # - An ENV is a string, not a boolean so you must compare to a string value:
            #   NOTE: Given the condition you might find `enable={{ is_default_branch }}` is simpler :)
            #   https://github.com/docker/metadata-action/blob/v5.9.0/README.md#is_default_branch
            # - `latest` condition should probably only be when publishing a new release?
            #   https://github.com/docker/metadata-action/issues/567#issuecomment-3579068205
            # - `type=raw,value=master` could also be `type=ref,event=branch,enable=...`
            #   which would tag with the branch name when the `enable` condition is met.
            #   Useful when workflow callers may use `main` instead of `master` as their default branch.
            type=raw,value=latest,enable=${{ env.IS_MASTER_BRANCH == 'true' }}
            type=raw,value=master,enable=${{ env.IS_MASTER_BRANCH == 'true' }}

            # If the value is not empty, you'll get this tag added too:
            # NOTE: Like the prior two suggestions, you may be able to use `value={{ tag }}` instead:
            # https://github.com/docker/metadata-action/blob/v5.9.0/README.md#tag
            type=raw,value=${{ env.RELEASE_VERSION }}

            # Optional - `semver` patterns (without `value` set, depends upon `github.ref_type == 'tag'` to set value implicitly):
            # - Unless there is a `v` prefix in the pattern, any `v` prefix from value is stripped:
            #   https://github.com/docker/metadata-action/blob/v5.9.0/README.md#typesemver
            #   https://github.com/docker/metadata-action/issues/422#issuecomment-2686231164
            # - `semver` has a high `priority` value; the first tag declared will be used for
            #   generating the implicit OCI image label `org.opencontainers.image.version`:
            #   https://github.com/docker/metadata-action/pull/562#issuecomment-3579397681
            # - Provide `:major` + `:major.minor` + `:major.minor.patch` tags (with your suffix appended)
            # - These are convenient for omitting the minor/patch versions at pull,
            #   or services that monitor a tag for when it's digest is updated for automation triggers.
            #
            #   Caution if you ever push tags that don't match the latest semver version in that series:
            #   https://github.com/docker/metadata-action/issues/407#issuecomment-2680650110
            type=semver,pattern={{major}}.{{minor}}.{{patch}},value=${{ env.RELEASE_VERSION }}
            type=semver,pattern={{major}}.{{minor}},value=${{ env.RELEASE_VERSION }}
            type=semver,pattern={{major}},value=${{ env.RELEASE_VERSION }}


      - name: 'Login to image registry (DockerHub)'
        if: inputs.publish_release == 'true'  # PRs do not have access to secrets
        uses: docker/login-action@v3
        with:
          registry: docker.io
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      - name: 'Login to image registry (ghcr.io)'
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

      # You could still use your `build-push-action` here, otherwise adapt to `bake-action`:
      # https://github.com/LizardByte/.github/blob/5189a41761ef8de8812a89c5a6ad120b5e777e63/.github/workflows/__call-docker.yml#L268-L287
      - name: 'Build'
        uses: docker/bake-action@v6
        # Docker Bake relies on ENV to update `variables` for build args,
        # Otherwise use `set` input for a targets `args` field.
        env:
          BRANCH: ${{ steps.prepare.outputs.branch }}
          BUILD_DATE: ${{ steps.prepare.outputs.build_date }}
          BUILD_VERSION: ${{ inputs.release_version }}
          COMMIT: ${{ inputs.release_commit }}
          CLONE_URL: ${{ steps.prepare.outputs.clone_url }}
          RELEASE: ${{ inputs.publish_release }}
          # The `DOCKERFILE` variable in `docker-bake.hcl` (if not handling it via `set` below)
          #DOCKERFILE: ${{ matrix.dockerfile }}
        with:
          # Use local filesystem (path context) instead of git context,
          # This is meant to be the equivalent to `build-push-action` input `context`:
          # https://github.com/docker/build-push-action#git-context
          # https://github.com/docker/bake-action/issues/352
          source: .
          files: |
            ./docker-bake.hcl
            # `docker/metadata-action` generated `tags`,`labels`,`annotations`:
            # (Alternatively use `bake-file-tags` for only the `tags`)
            cwd://${{ steps.image-metadata.outputs.bake-file }}
          # `targets` input can be omitted as it's already what the group `default` uses:
          #targets: sunshine,artifacts
          set: |
            # Building different variants like your CI setup currently does:
            sunshine-builder.dockerfile=${{ matrix.dockerfile }}

            # Applying this setting to all targets in the Bake config (includes `sunshine-builder`):
            *.no-cache-filters=${{ steps.prepare.outputs.no_cache_filters }}

            # Caching the `sunshine` target should cover the earlier build stage layers:
            # (thus `artifacts` target will also benefit in future builds)
            sunshine.cache-from=["type=local,src=/tmp/.buildx-cache"]
            sunshine.cache-to=["type=local,dest=/tmp/.buildx-cache"]

            # While there's no need to cache `artifacts` target, you would want to match `platforms`:
            # (Think of the `sunshine-builder` target as similar to multi-stage image builds)
            sunshine.platforms=${{ steps.prepare.outputs.platforms }}
            artifacts.platforms=${{ steps.prepare.outputs.platforms }}

            # Only conditionally push/publish the `sunshine` target:
            # NOTE: If `sunshine-builder` inherited `sunshine` instead you would need to unset `push`,
            # or use the long-form `output` syntax for pushing the `sunshine` target
            sunshine.push=${{ inputs.publish_release }}

EDIT: Oh, that final docker/bake-action usage with set isn't very generic/portable 😓 (I guess you'd need to have the workflow caller provide that, or perhaps without generic conventional target names that isn't that usable for you vs docker-push-action) You could shift them to generic variables to pass in via env?

NOTES:

• Docker Bake moves a bunch of inputs docker/build-push-action has into the set input for docker/bake-action since you can think of it as syntax for handling multiple docker/build-push-action steps for different images.
• tags was configured based on your prepare script logic. I think it's nicer to manage the tags via docker/metadata-action instead personally, much more readable?
• I can see why you may not want to use the docker/metadata-action conveniences (global expressions) given that those inputs are still used elsewhere such as build args for the image which additionally maps some ENV into the cmake/package build process (COMMIT => GITHUB_COMMIT).
  • Perhaps it'd be useful if docker/metadata-action could also support args as an input/output in that sense 😅 (unfortunately it seems args output is already used?)
  • You can leverage labels output which has quite a few of these that match your needs (or their rough equivalents with GHA expressions).
• matrix.tag represents the Dockerfile variant (name.Dockerfile => -name).
• docker/metadata-action generates implicit labels (in addition to any of your own, which will override their equivalent implicit default labels output). This is only relevant information if you intend to use the labels output (as the implicit list isn't documented officially).

[ReenigneArcher]

Thank you for the detailed responses! I will probably look into bake in the future, but for now I have migrated the archlinux build away from our docker workflow.