-
Notifications
You must be signed in to change notification settings - Fork 148
Description
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:
- Bake: target override using file breaks references to its tags list from other target buildx#3173 (comment) (primary tracking issue)
- Null value for
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-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
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