Package: workflow-templater
IntroTemplate engine for (currently) Jira and Email. Uses yaml and jinja2. It helps you create multiple (possibly cross-linked) jira issues and emails from a template.Table of ContentsIntroTable of ContentsInstallationWindowsmacOSAnything else (GNU/Linux, Cygwin, *nix, etc)Using pipUsing pipxFrom sourceUsageConfigurationTemplate descriptionOverviewExamplesInstallationWindowsDownload Workflow_Templater_${version}.exe from the latest release onReleases page.Install it.Nowworkflow-templaterexecutable should be available from Windows Command Prompt (cmd.exe) and from Powershell.(Optional, recommended) InstallWindows Terminaland use it instead of default console.macOSInstall python ≥ 3.10.Using official Python installer:Install python ≥ 3.10 fromhttps://python.org/("macOS 64-bit installer")Install CA certificates for python, execute in Terminal:/Applications/Python\ 3.7/Install\ Certificates.commandAlternatively, you can double-click onInstall Certificates.commandin FinderOr usingHomebrew:brewinstallpythonpip3installworkflow-templaterAnything else (GNU/Linux, Cygwin, *nix, etc)Using pipMake sure that python ≥ 3.10 is installedpip3installworkflow-templaterUsing pipxpipxrunworkflow-templaterFrom sourceClone this repoInstall dependencies if requiredpip3install-rrequirements.txtYou can execute the script directly:cd workflow_templater
./workflow_templater/__init__.py --helpOr install/build/whatever it withpython3 setup.pyUsageSeeworkflow-templater--helpConfigurationTo avoid typing same command line arguments each time, it is possible to specify them in configuration file. Configuration file location is OS-specific, to find out correct location for your os, executeworkflow-templater --help, you'll see message "--config CONFIG  overwrite config file path, default is ${location}" where ${location} is the location of configuration file on your OS. You can create this file and specify values of command-line arguments omitting--and replacing-with_, for example,--jira-user j_waynebecomesjira_user: j_wayne,--dry-runbecomesdry_run: trueand so on. You can also use jinja2 in configuration file which evaluates using variables from itself.Example~/.config/workflow-templater/config.yaml:dry_run:trueverbose:trueuser:j_waynejira:https://jira.example.com/jira_user:'{{user}}'email_user:'{{user}}'email_from:'{{user}}@example.com'email_smtp:'smtp.example.com:587'# avoid typing in the same password for jira and emailjira_keyring_service_name:'MyCorpLDAP'email_keyring_service_name:'MyCorpLDAP'Template descriptionOverviewWhole workflow template is a directory.There should be one file with variables named0_common.yaml,00_common.yamlorcommon.yaml. Alternatively, you can name this file as you wish and specify its name with--varsargument.There may be any amount of "issue" files:ending with ".jira.yaml" for jira issueAll fields in each jira.issue file are send as is to Jira viaAPIinfieldsfileld with the exception of following fields:watchers: it's impossible to add watchers during create so it handled separately viathis API method.update: its content is sent inupdateviaAPIglobal special fields (see below)ending with ".email.yaml" for email.There may be optional file namedmutate.pywith functionmutatewhich accepts variables, modifies them and returns the result wich can be used in templates.Basic example:defmutate(variables):variables['new_variable']=f'{variables["old_var1"]}and{variables["old_var2"]}'returnvariablesSecurity note: if you concerned that this feature introduces an ability to execute arbitrary code from the templates, that's correct. However, this is also possible with bare jinja templates (seehttps://github.com/pallets/jinja/issues/549), so you should make sure that your templates come from trusted sources anyway.Each "issue" file is yaml file where each string value is rendered withJinja2using variables from*common.yamlfile.Special variables available for use in jinja:issuekey_self: Jira issue key or Message-ID of current issue or email.issuekey_<name>: Jira issue key or Message-ID of issue or email named<name>. For example, for issue in filenamesomething.jira.yamlthis variable name would beissuekey_somethingand it can be used in all templates.Global special fields:foreach: list, create one issue per item in this list. List items should be strings or dicts (in case of dicts you must specifyforeach_namevartoo, see below). In case of strings, issuekey_ variable would be namedissuekey_<name>_<list_value>Example:foreach:-Android-iOSsummary:'Releaseapplicationfor{{item}}'...would finally evaluate to following issues:summary:'ReleaseapplicationforAndroid'...summary:'ReleaseapplicationforiOS'...foreach_fromvar: if content forforeachvariable is shared between several templates, it's better to specify it in*common.yamlfile and specify here the name of the variable in this file. Example:common.yaml:OSes:-Android-iOS...build.jira.yaml:foreach_fromvar:OSessummary:'Buildclientsfor{{item}}'...release.jira.yaml:foreach_fromvar:OSessummary:'Releaseapplicationfor{{item}}'...foreach_key: if you don't like default variable name (item) for each item inforeachlist, you may specify it here. Exampleforeach:-Android-iOSforeach_key:ossummary:'Releaseapplicationfor{{os}}'...would finally evaluate to following issues:summary:'ReleaseapplicationforAndroid'...summary:'ReleaseapplicationforiOS'...foreach_namevar: when foreach is in use, workflow-templater would generate issuekey_ variable name as follows:issuekey_<name>_<list_value>. If you use dicts as foreach values, you need to specify key name in this dicts which will be appended to the end of this variable name. Examplerelease.jira.yamlfile:foreach:-name:Androiddate:!!timestamp2019-10-24 06:30:00.0-name:iOSdate:!!timestamp2019-10-24 10:50:00.0foreach_namevar:namesummary:'Releaseapplicationfor{{item.name}}'...Now in any other (or the same) issue you can link to this issues as follows:summary:'Notifycommunity'description:|Android release task: {{ issuekey_release_Android }}iOS release task: {{ issuekey_release_iOS }}if: if this variable value evaluates to empty string (''),falseorno, this template will be completely ignored. Note: value for this variable is calculated for each item separately whenforeachorforeach_fromvaris in use.
Example:foreach:-Android-iOSforeach_key:osif:'{{osin["Android","GNU/Linux"]}}'summary:'Releaseapplicationfor{{os}}'...would finally evaluate to following issue (only one, obviously):summary:'ReleaseapplicationforAndroid'...ExamplesSeebasic release examplefor basic example.