v5.5.0 Broke docker/bake-action with docker-metadata-action

[mldmelissa]

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

Bumping the version from 5.4.0 to 5.5.0 broke the usage of target "docker-metadata-action" {} with docker/bake-action@v4. When using 5.4.0, I was able to override the tags defined in my docker-bake.hcl file with the outputs of the docker/metadata-action, but now the tags no longer get overwritten with 5.5.0.

Expected behaviour

I would expect that if I have the following in my docker-bake.hcl file, the output of docker/metadata-action@v5.5.0 would override the tags defined in the targets.
``
target "docker-metadata-action" {}

target "_common" {
inherits = ["docker-metadata-action"]
}

target "example1" {
inherits = ["_common"]
tags = ["example1:latest"]
}
``

Actual behaviour

The outputs from docker/metadata-action@v5.5.0 do not override the tags defined in my docker-bake.hcl. When using v5.4.0 of docker/metadata-action, the tags were successfully overwritten.

Repository URL

No response

Workflow run URL

No response

YAML workflow

- name: Extract Docker metadata for data_manager
        id: meta
        uses: docker/metadata-action@v5.5.0
        with:
          images: ${{ env.REGISTRY }}/${{ github.repository }}_${{ matrix.target }}
          tags: |
            type=schedule
            type=ref,event=branch
            type=ref,event=tag
            type=ref,event=pr
            type=raw,value=latest,enable={{is_default_branch}}
            type=sha
          bake-target: ${{ matrix.target }}
      - name: Build and push
        uses: docker/bake-action@v4
        with:
          targets: ${{ matrix.target }}
          files: |
            ${{ steps.meta.outputs.bake-file }}
            ./docker-bake.hcl
          push: true
          set: |
            *.cache-from=type=gha,scope=${{ matrix.target }}
            *.cache-to=type=gha,scope=${{ matrix.target }},mode=max

Workflow logs

No response

BuildKit logs

No response

Additional info

No response

[ekostjuk]

Took me a while to land on this as it tries to use default registry for non-registry tagged images with 401, which is a red herring. Related error Error: buildx bake failed with: ERROR: failed to solve: failed to push ...: failed to authorize: failed to fetch oauth token: unexpected status from GET request to https://auth.docker.io/token?scope=repository ...

[mldmelissa]

Took me a while to land on this as it tries to use default registry for non-registry tagged images with 401, which is a red herring. Related error Error: buildx bake failed with: ERROR: failed to solve: failed to push ...: failed to authorize: failed to fetch oauth token: unexpected status from GET request to https://auth.docker.io/token?scope=repository ...

I get that similar authorization failed message with trying to push, when this exact same workflow works with v5.4.0. I can see that it is trying to push my_container:latest, which it should be trying to push ghcr.io/my_org/my_container:pr-123@sha256:12345... I am not sure what changed to make it use the local "tags" field in the hcl file over the docker meta data.

**#23 ERROR: failed to push my_container:latest: push access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

exporting to image:

ERROR: failed to solve: failed to push my_container:latest: push access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
Error: buildx bake failed with: ERROR: failed to solve: failed to push my_container:latest: push access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed**

[crazy-max]

Yes this is similar to what has been reported in #370 (comment)

It seems the merge logic of the bake definitions does not happen in the specified order when cwd:// prefix is used. I will make some changes in this action first and follow-up on buildx repo. Sorry for that.

[mldmelissa]

Yes this is similar to what has been reported in #370 (comment)

It seems the merge logic of the bake definitions does not happen in the specified order when cwd:// prefix is used. I will make some changes in this action first and follow-up on buildx repo. Sorry for that.

Awesome, thanks for working on that fix!