Support Bake output with attributes (instead of only a target)

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

I don't personally have this issue as a blocker, it's probably niche for users of docker/metadata-action but a report is missing so I've filed one for the benefit of others.

---

Reference:

• https://github.com/docker/buildx/issues/3173#issuecomment-3587852919 (primary tracking issue)
• https://github.com/docker/buildx/issues/3540#issuecomment-3587888620 (docker/metadata-action specific case)

In the first issue linked I better describe the technical concerns of trying to reference a bake target fields separately (such as via target.docker-metadata-action.tags), this works fine unless the target has been defined again with an override that doesn't have the referenced field present.

The 2nd linked issue occurs because of override order for the same docker-metadata-action target when the user additionally wanted to include the annotations output (opt-in).

As the current advice for using the bake output files keeps it simple with inherits = ["docker-metadata-action"], this is only an issue when using targets.docker-metadata-action.<field name> as detailed across the two linked issues.

The most likely error case above would be when including annotations, where it needs to be placed earlier (would require a documentation fix).

---

Proposed solution - HCL attributes

Another approach is to use the global scope attributes (JSON compatible but attributes are presently undocumented in Docker Bake docs), where these could be namespaced which would avoid the target reference problem if using the attributes instead?

The bake config files generated (via iterator) could still include the docker-metadata-action target for use with inherits as is currently advised in docs, but now the target fields of interest could instead by referenced via their associated attribute?

bake-file:

docker-metadata-action_tags = [ ... ]
docker-metadata-action_labels = { ... }
docker-metadata-action_args = { ... }

target "docker-metadata-action" {
  tags = docker-metadata-action_tags
  labels = docker-metadata-action_labels 
  args = docker-metadata-action_args 
}

bake-file-annotations:

docker-metadata-action_annotations = { ... }

target "docker-metadata-action" {
  annotations = docker-metadata-action_annotations
}

This is more work to resolve (and still requires a docs update), but I figured it may be worth documenting.

Expected behaviour

The Bake target block override order from this action not preventing access to individual target fields.

Actual behaviour

https://github.com/docker/buildx/issues/3540#issuecomment-3587888620

Repository URL

No response

Workflow run URL

No response

YAML workflow

# ...

      - name: Docker meta
        id: meta
        uses: docker/metadata-action@v5
        with:
          tags: |
            type=raw,value=latest

      - name: Build and push
        uses: docker/bake-action@v6
        with:
          scope: .
          files: |
            ./docker-bake.hcl
            cwd://${{ steps.meta.outputs.bake-file }}
            cwd://${{ steps.meta.outputs.bake-file-annotations }}

Workflow logs

No response

BuildKit logs

Additional info

No response

Start with the linked Buildx issues and the bake-file generation paths in src/meta.ts and src/main.ts. Compare the existing bake-file and bake-file-annotations outputs with the documented inheritance and override cases; done means determining and documenting a supported way to access the generated metadata without target-field override-order problems.