-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
community.docker.docker_image_build: outputs[] is not recognized #1001
Comments
The module simply runs |
@felixfontein nice suggestion, I've run some test nad it seems like this : works as expected, but this:
produces only test:default docker image. So to me it seems like docker buildx ignore --output flags when --tag flas is passed. As far as I understand a code of the library, here is said:
I tried to propose PR where it's something like "required if not output specified" but I couldn't find any docuemntation about required_if and mutualy_exclusive params, like there:
And I can't propose something that I'm confident is working :( Maybe making name optional will be a solution? Or mutualy exclusive with output params? It does seem like intended buildx workflow as I can't see any issues about it and all documentation reffers to --outputs with --tag ommited. |
Screwing around with the module's inputs is not the right solution. We have to figure out what to pass to |
While browsing in the buildx code I found: https://github.com/docker/buildx/blob/master/build/opt.go#L189, I traced this back to docker/buildx@a932d52. I'm not sure whether this is actually on the relevant code path, I have to check in more detail when I have more time. |
Thanks for that insight. I see that in first link that you attached the attribute 'tag' is mapped to opt.Exports[i].Attrs["name"]. But do you think it's relevant to our case? It seems to me like internal buildx stuff that shall not be visible from outside. I've tried something like that: Why do you think altering module inputs is not an option? For me it seem most intuitive. We map this:
docker buildx build --tag some_name:1.0 So if buildx doesn't require --tag parameter ( with outputs) why shall we? If we keep that 'name' required, if I want to get two tags - 1.0 and latest, I have only two options:
Which you can see is quite odd. For comprasion, this one:
looks super clean. So IMO, we can map the name parameter to outputs instead of --tag and it will allow to function it properly but is quite confusing. Making name optional when outputs are defined feels more intuitive. What do you think? |
I didn't have time right now to read contributer guide, I may do PR later so it's easier to talk, but I see that wit the chagne to file plugins/modules/docker_image_build.py:385 to |
I added a lot of debug output to buildx and was able to verify that it's exactly the reason why only When running Why this was implemented this way I have no idea. I traced the behavior back to docker/buildx@4b0c046; back then it was only possible to specify In any case, the solution seems to be to leave Making type configurable doesn't make sense, since the module assumes that the build output is always tagged as specified in I have to think more about this... |
I've checked after looking at the code you've send, that: However in ansible if you create role like that:
There is an warning:
Therefore we can't reprocude it 1:1 I guess. I think that this:
Is the best solution. Actually in that scenario, there is no need to change --tag to --output. Logick can be "use --tag name:tag only if there is no --output specified". I personally think that leaving outputs and staying only with --tag is big step backward as specifing multiple ouptuts is super handy. In more complex scenario you can specify for ex. 3 outputs to push to 3 different repos (ex. dev, qa, prod) . Without outputs you'll need to define role/task 3 times. Let's think about this but I think that it is a good solution. |
Either way it would be nice to do any plan for it :D I need to decide whether to develop workaround for this bug/missing feature or we can fix it relatively soon |
Hi @felixfontein , those are cool changes. I've tested it and I've managed to get outputs almost work with this:
As expected it's a bit weird to have to define root.name if that s not used but in this config both image tags are build. However, it does weird thing when pushing. In this configuration, I expect two tags "ansible-docker:1.0" and "ansile-docker:2.0" to be pushed as Image Index, and then without a tag actual images that relates to that. It seems to be achievable with:
But with current proposition, 1:0 is Image index, 2:0 is an image, and second Image Index is left untagged. There is still something off :( What do you think? |
I adjusted the PR to now accept a list of strings for |
SUMMARY
outputs[].name has no effect on final build
ISSUE TYPE
COMPONENT NAME
community.docker.docker_image_build
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
ubuntu 22.04 on windows WSL
STEPS TO REPRODUCE
EXPECTED RESULTS
Image with '{{ repository }}/{{ image_name }}:{{ version }}' and '{{ repository }}/{{ image_name }}:latest' are pushed to repository
ACTUAL RESULTS
Only Image '{{ repository }}/{{ image_name }}:{{ version_default }}' is pushed.
The text was updated successfully, but these errors were encountered: