WARNING: THIS SITE IS A MIRROR OF GITHUB.COM / IT CANNOT LOGIN OR REGISTER ACCOUNTS / THE CONTENTS ARE PROVIDED AS-IS / THIS SITE ASSUMES NO RESPONSIBILITY FOR ANY DISPLAYED CONTENT OR LINKS / IF YOU FOUND SOMETHING MAY NOT GOOD FOR EVERYONE, CONTACT ADMIN AT ilovescratch@foxmail.com
Skip to content

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

@polarathene

Description

@polarathene

Contributing guidelines

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:

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

docker/buildx#3540 (comment)

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions