bake: allow attributes in global scope #541
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
depends on #539 #538
I propose this as a base for #489 (review)
You can now define global scope attributes in HCL/JSON and use them for code reuse and setting values for variables. This means you can do a "data-only" HCL file with the values you want to set/override and use it in the list of regular output files.
Eg.
You can use this file directly or create an override configuration file
and invoke bake together with both of the files.
So instead of loading a
.env
automatically with another custom format, you can just pass any config file. The HCL attributes are not 100% compatible with env file format so I think for compose support we still should have a fallback, and maybe still automatically load it if you parse compose. Possibly we can just use the new compose library that does that automatically on parsing compose. For everything else, you can use HCL/JSON attributes.In addition to strings HCL file attributes also support custom data types: arrays, booleans etc. You can refer to other attributes or call built-in functions(user functions not supported atm).
The difference between variables and attributes is that only variables are configurable by the user on invocation. I think this distinction is important, for example in the future I would expect that we add a "description" property to variables so we can show the user what variables are accepted and what do they mean.
I think we should also do #445
@crazy-max @tiborvass @thaJeztah @vanstee