-
Notifications
You must be signed in to change notification settings - Fork 32
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
Add template-level parameters and file_name
per template config
#294
Conversation
file_name
per template configfile_name
per template config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good BUT I find the weaver config confusing.
I think we should deprecated pattern
for template
.
Specifically:
templates:
- pattern: test.md
filter: .
application_mode: single
params:
template_name: test1
test_1: true
file_name: "{{params.template_name | snake_case}}.json"
Looks confusing, since test.md
is the template you're using, not a pattern at all.
Instead, let's do:
templates:
- template: test.md
filter: .
application_mode: single
params:
template_name: test1
test_1: true
file_name: "{{params.template_name | snake_case}}.json"
I think we can do this in a non-breaking way by deprecating the "pattern" attribute and adding "template" where we pull from pattern if it exists, otherwise use template.
Can be done with a serde alias. I will also update the docs. |
…attern as serde alias for back-comp
@jsuereth I renamed |
This PR adds two new optional fields in the
templates
section of a Weaver configuration file:params
: Defines a map of key-value pairs which will be merged with the ones defined at the top level of theweaver.yaml
file. CLI parameters can also be used to override these parameters.file_name
: Defines the relative file path of the output generated from the template. This field is a Jinja expression which will be evaluated with the same context used in the template itself. The parameters mentioned above are also accessible.An example of usage:
Note:
params
are now merged in an additive way. For example, if a parameter is defined in theparams
section of a template, then the finalparams
section for this template will include both theparams
inherited from the file-level configuration and theparams
defined in the template configuration. If the override is a parameter set to null, then this parameter is removed from the finalparams
section. This modification should not have a significant impact on the existing codegen, as I don't believe any codegen was relying on this specific behavior.Closes open-telemetry/weaver#288.