Repository navigation
Allow exposing arbitrary structured data to jinja context #1312
Description
Activity
@c0m1c5an5, interesting idea. What if I just expose the json parser function into the context? There is already a
read_filefilter added to the context and this would convert it to usable JSON. You would need to hardcode the filename into your custom templates though.Reacted by Paulo Ferreira de Castro@codejedi365 Yes, that provides even more options for the end user than I intended. This is probably the best option.
Reacted by codejedi365Add a cli flag (for example --data) that takes in a json string.
Indeed, I have come across this issue while looking for a way to expose data from CI environment variables to the context in Jinja templates. Reading JSON from a file works for sure, 👍 but in simple cases like trying to load a short string of comma-separated items such as
'item1,item2,..., it would be rather convenient to have a solution like:# CI shell script export MY_ITEMS='item1,item2,item3' ./venv/bin/semantic-release version --env MY_ITEMS --changelog --vcs-release ...
or
./venv/bin/semantic-release version --env MY_ITEMS='item1,item2,item3' --changelog --vcs-release ...And then in the Jinja template, something along the lines of:
{% for item in context.env.get('MY_ITEMS', '').split(',') %} * This item’s value is {{ item }}. {% endfor %}
Above I've used Python’s syntax for the dict.get and str.split methods, which should be available in Jinja according to Python Methods in Jinja. Related StackOverflow post: Accessing OS environment variables from Jinja2 template.
Neither JSON nor files are needed in this example. This would be an additional solution to the alternative of reading JSON from files.
Either way, great stuff! 👍🚀
semantic-release version --env ...
Similarly to the
docker run --envoption: https://docs.docker.com/reference/cli/docker/container/run/#env@c0m1c5an5, thanks for the example. I started reviewing them and will see how many I add from ansible's implementation.
@pdcastro, thanks for adding to the discussion of what you would like too. I probably will not use a CLI option like docker but likely something similar to the
build_command_envoption (changelog.context_env) and the env get added to the context as your example asks. The reason for having it specified is similar to docker in defining the env values to pass. It prevents an arbitrary passing of secrets into a context which are hard for a program to determine which the user would never intentionally pass.Reacted by Paulo Ferreira de CastroIt has been 90 days since the last update on this confirmed issue. @python-semantic-release/team can you provide an update on the status of this issue?
Feature Request
Allow user to provide additional data to be exposed in the jinja context for changelog generation.
Description
Allow user to pass arbitrary json-formatted data for use in the template interpolation.
Use cases
The most common use case is passing dynamically generated data to the changelog like docker container hashes, built binary checksums, etc.
Possible implementation
Add a cli flag (for example --data) that takes in a json string. Parse that string and add it to the jinja context under the
user_datakey. This gives the most flexibility to the user. Though, having an ability to pass a json file would also be nice, since there can be cases, where shell command length limit is reached. If this implementation is approved, I can create a PR with these changes.Alternative solutions
I currently use this workaround: