Closed crazy-max closed 2 months ago
This looks useful, but wondering if we want to limit it to just targets; variables could be important as well (?) Perhaps a command that (pretty)prints information about the bake file?
Why exclude targets without a description? I think its useful to have them printed regardless
We should also take a look at what is currently done in just: https://github.com/casey/just#command-line-options
This looks useful, but wondering if we want to limit it to just targets; variables could be important as well (?) Perhaps a command that (pretty)prints information about the bake file?
I think this is a slightly different case than printing out the targets/groups, as far as I'm aware the variables are an hcl-level concept, and are removed upon parsing?
I think this is a slightly different case than printing out the targets/groups, as far as I'm aware the variables are an hcl-level concept, and are removed upon parsing?
Possibly, yes. My view on this was; "what information would I be looking for (as a user) that I can pass to buildx bake
to control the build?"; one of that is the target to build, but other parameters can be variables that it takes.
Is there anything blocking starting development on this? I'm happy to take a look.
I wonder if we could automagically extract descriptions from the Dockerfile using the new --print
feature, if the target stage has a comment? And then allow overriding with the description
bake field?
This seems to have already been done in https://github.com/docker/buildx/pull/2556. I'm going to close this issue.
Atm the bake definition needs to be opened to find out available targets. This is not practical and should be available through the cli.
Suggest to add a
--targets
or--list
flag forbake
cmd that would list the available targets.Targets would need a
description
field to be displayed:Targets that don't specify a
description
will not be displayed.This flag cannot be used if a target is specified.
For compose it might be tricky as there is no such field in the compose spec that we could use. Maybe a comment can work in this case but not supported with JSON format:
Or an extra arg to target:
But again not suitable for a JSON representation as well as a compose file.
Open to suggestions.