How to increment a date variable inside a 'For Each' branching ?

[TP]

My objective is to setup sequential stories within different Epics. I am looping through the epics and would like to have a staggered start date so that each epic starts at a different date.

I have created a startDate variable before the branching.

Within the branch, I'm trying to increment it so that in the next loop, the date to be used is the incremented one.

I understand the branches in fact run in parallel so this solution does not work.

What is the recommended way to achieve what I want ?

Stylized version of my automation below

[Trudy P Claspill · Accepted solution]

Hello @TP 

It is not currently possible to increment a variable in a branch. That change request is included in this change request, to which you can add your vote:

https://jira.atlassian.com/browse/AUTO-26

[TP]

Thanks for your quick reply - have added my vote indeed.

[Bill Sheboy · Accepted solution]

Hi @TP 

As Trudy described, that variable cannot be re-declared to update it, or to update it sequentially.

For this type of scenario, there is a workaround for the parallel processing of branches using variables, and it requires some assumptions:

• you have fewer than 100 items in that branch
• you are willing to rename that variable {{startDate}} to something like {{varStartDate}} to avoid the risks of name collisions
• you want to increment each date by the same amount; for example, X days
• you are entering the "epic names" for the new issues in the desired, date order
• you are entering the "epic names" with some delimiter, such as a comma
• you pair with your teammates to explain this rule, ensuring it can be understood and maintained :^)

Now, the how-to part:

List elements have an index, or counter for each item.  They are numbered 0 for the first item, 1 for the second, and so forth.  Please look here for documentation on index: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#Combined-function-examples

And so {{index}} would be a great thing to use for your list of epic names as a way to multiply a number of days to increment the date.  The problem is {{index}} appears to be unavailable for anything other than displaying the number: it cannot be used in a function, such as {{someDate.plusDays(index)}}

But what if we could capture the index for use later to increment the date variable?  We can!

First convert your manual trigger, input variable of epic names into a list stored in a variable, using the split() function and {{.}} for item value:

• action: create variable
  • name: varEpicNameAndIndex
  • smart value:

{{#userInputs.epicNamesString.split(",")}}{{.}},{{index}}{{^last}};{{/}}{{/}}

This will produce a variable value like this, where we have name / index pairs:

make plan,0;buy materials,1;build shelf,2;store books,3

For the branch over the values, we split that back apart into pairs:

• advanced branch
  • name: varOneEpicAndIndex
  • smart value:

{{varEpicNameAndIndex.split(";")}}

Inside of the branch, we may how access and use the two parts like this:

epic name: {{varOneEpicAndIndex.split(",").get(0)}}

new date: {{varStartDate.toDate.plusDays(varOneEpicAndIndex.split(",").get(1).asNumber)}}

Please adjust the date increment and delimiters, as needed.

Interestingly, I have seen several questions in the last few weeks that can be solved using this same technique of build-your-own-list, sometimes including dynamic searching.  Perhaps its time to write an article to generalize this a bit for reuse.

Kind regards,
Bill

[TP]

Very nice if just a little bit hacky :)

In truth, Atlassian should productionize this so we don't have to go through the hack.

[Bill Sheboy]

I'd suggest this type of workaround is more than a little bit hacky, although likely to continue working after future automation improvements ;^)

There is an open suggestion to add an option for parallel versus sequential execution of rules (such as for branches).  You may vote for / watch it to see any progress: https://jira.atlassian.com/browse/AUTO-32

Given the potential for service limit violations when a hypothetical, sequential rule runs too long I hypothesize this suggestion may not be implemented without another limit change by Atlassian.