Contributing guidelines
I've found a bug, and:
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
Contributing guidelines
I've found a bug, and:
Description
I don't personally have this issue as a blocker, it's probably niche for users of
docker/metadata-actionbut a report is missing so I've filed one for the benefit of others.Reference:
tagswhen using withdocker/metadata-actionbake file output buildx#3540 (comment) (docker/metadata-actionspecific 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-actiontarget 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 usingtargets.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-actiontarget for use withinheritsas is currently advised in docs, but now the target fields of interest could instead by referenced via their associated attribute?bake-file:bake-file-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
Workflow logs
No response
BuildKit logs
Additional info
No response