m-khvoinitsky / workflow-templater

Template engine for (currently) Jira and Email. Uses yaml and jinja2. It helps you create multiple (possibly cross-liked) jira issues and emails from a template.
MIT License
6 stars 3 forks source link

Recursive common values #2

Open dmfs opened 3 years ago

dmfs commented 3 years ago

Config values can contain template code which refers to other config values, e.g.

user: j_wayne
jira: https://jira.example.com/
jira_user: '{{ user }}'

Unfortunately that doesn't seem to work with values in the common file.

For instance, consider a common file like this:

guest=c_eastwood
tasks:
   - title: Lunch
     description: "Take [~{{guest}}] out for lunch."
   - title: Tour
     description: "Show [~{{guest}}] around the office."

And a generic task like this:

foreach_fromvar: tasks
summary: '{{ item.title }}'
…
description: |
   {{ item.description }}

At present the task contain literally [~{{guest}}] instead of [~c_eastwood].

Ideally common values could take advantage of this kind of recursion, just like config values do. Does that make sense or am I getting something wrong here?

m-khvoinitsky commented 3 years ago

Well, it makes sense but initially I didn't want to do this in order to not overcomplicate everything and make it more predictable. Config file is usually consists of only a few lines, templating here is useful and you can't achieve the same results without it.

Regarding your example: foreach_fromvar is supposed to be used in the same action but for different items (whatever it is). Something like this:

common.yaml:

guests:
- j_wayne
- c_eastwood

lunch.jira.yaml:

foreach_fromvar: guests
summary: 'lunch with {{ item }}'
…
description: |
   Take [~{{ item }}] out for lunch.

tour.jira.yaml

foreach_fromvar: guests
summary: 'Tour for {{ item }}'
…
description: |
   Show [~{{ item }}] around the office.
dmfs commented 3 years ago

I had separate files before, but it turned out they have mostly the same content, except for summary and assignee. So I made a list in my common file like so

tech_briefings:
    - name: "Technology 1"
      assignee: some.teammember
    - name: "Technology 2"
      assignee: some.other_teammember
    - name: "Technology 3"
      assignee: some.teammember
    - name: "Technology 4"
      assignee: some.other_teammember
// … 15 more tech briefing topics …

and a generic subtask which loops over these. That works great and whenever I need to instantiate the task I just need to check one file, remove any tech briefings I don't need and update the assignee if necessary. I don't need to scan 50 files to check which ones I have to remove or update. I have other subtasks in the structure and this method brought the number of files down from 50 to 30.

The only limitation is that template expressions are not evaluated within such a list.

Here is another use case for this (assigning roles to each tech briefing instead of users):

qa_engineer: team.member1
java_engineer: team.member2

tech_briefings:
    - name: "Technology 1"
      assignee: '{{ java_engineer }}'
    - name: "Technology 2"
      assignee: '{{ java_engineer }}'
    - name: "Technology 3"
      assignee: '{{ java_engineer }}'
    - name: "Technology 4"
      assignee: '{{ qa_engineer }}'
// … 15 more tech briefing topics …

I know that this works when I put each subtask into its own file. But that doesn't scale very well.