Automation, looping through looked up issues, capabilities

[Ryan McBryde]

This is in a similar vein to other automation questions that I have seen, and asked, here and I am hoping for some help with this particular application.

I have an external job which uses the Jira API to create issues in Jira automatically based on test failures detected in another system.  That API job works well and dutifully creates an issue for every Test Failure.  We are seeing that in some cases, the API creates a series of test failures that are all spawned from the same test and we want to capture each of them, however we want to id the first one as the original and all others, that match the same criteria, as duplicates.  I am discussing with the engineer if it makes more sense to perform this "duplicate detection" logic in the API and simply add the link to the "dups" when creating the issues originally.  In the meantime, I am trying to test the viability of doing the "duplicate detection" in Jira, using automation, and it appears that the "Lookup Issues" action would suit this very well, with the one, albeit major" issue of a lack of the ability to loop thru the "array" returned by the lookup.  I am sharing my basic logic here in hopes that some of you more experienced folks can help me determine if this is possible and if so, how.

My Logic:

Test Failure (TF) created

Is Reporter the service account used by the API?

If yes. is the pipeline id from Git stored on the TF populated?

If yes, use Lookup Issues to find all TFs that are not in DONE status and that have the same Git pipeline id as the TF being created.

Are there other TF issues that fit this criteria?

If yes, then loop thru the list of TFs returned and determine which is the "FIRST" one created, using the id #  (or issue key).

Identify the "FIRST" one as the original Test Failure issue (possibly by setting a boolean field to Yes but haven't tried this yet)

Once "original" is identified, link all remaining (matching) TFs to it using the Duplicate/Duplicated By issue link type. (If not already linked using this link type)

Any assistance would be welcomed, or a declaration that this cannot yet be done with Jira Automation.

Thnx

[Bill Sheboy · Accepted solution]

Hi @Ryan McBryde 

This seems possible with Automation for Jira with Cloud.  Here are some things from your notes to address:

Are there other TF issues that fit this criteria?

Are there other criter that what you stated?  If it is just what you described, you can find those issues.

Identify the "FIRST" one as the original Test Failure issue...

This is the part where you will need to combine the use of LookupIssues and Branches to succeed.  Here is a general outline of the rule, based upon your notes.  I recommend adding extra audit log actions to track progress.

• Trigger: issue created
• Action: re-fetch (Given potential timing issues, I suggest adding this to slow down the rule and ensure the issue is fully loaded at execution time.
• Condition: Is Reporter the service account used by the API?
• Condition: Is the pipeline id from Git stored on the TF populated?
• Action: Lookup Issues to find all TFs that are not in DONE status and that have the same Git pipeline id as the TF being created *except for the triggering issue*.
• Condition: {{lookupIssues.size|0}} is greater than zero  -- confirm there are issues to process
• Action: create variable with the first key from the lookup: varFirstKey set to  {{lookupIssues.key.min}}
• Branch: on the same JQL from your lookup, and now including the trigger issue and instead excluding {{varFirstKey}}
  • Action: link the issues as you noted

Best regards,

Bill

[Ryan McBryde]

Thank you Bill for the thoughtful and informative reply.  I will try this, and thank you for the tip on the re-fetch.

My current rule is as follows:

On New Issue creation, check to see if type is TF, if reporter is the service account and if the pipeline id field is not empty.

If so, run Lookup Issues, with search criteria equal to:  TF status not Done, AND the pipeline id matches the one on the TF being created.  

I assuming that this rule will fire for each TF being created, so I am checking the {{lookupIssues.size}} each time, and when that value is equal to 1, I am taking that one as the "original" and struggling with how to use that information in the rest of the rule.  Using if/else to id original.  If size is 1 then it's the original, else it is a duplicate.  I had created a variable called "OriginalTestFailureIssue" was storing the  issue.key there but having problems referring to it when processing the dups.

So it sounds like I was on the right track and will modify to follow your logic above. I look forward to reporting a successful outcome.

Thanks again

[Ryan McBryde]

Are you using an if/else condition or an Advanced Compare for the " {{lookupIssues.size|0}} is greater than zero" check?

[Bill Sheboy]

I believe you need the advanced compare condition to test that one.

[Ryan McBryde]

Thank you Bill,

I had to make a slight change to the code that you sent, using {{lookupIssues.id.min}} instead of {{lookupIssues.key.min}} for the customvariable varFirstKey. It appeared that the min, being a math function, couldn't operate on the key field but it was able to operate on the id field, as it is a numeric.  That gave me a way to exclude the "original" TF from the lookup for duplicates, and I tested with a generated email to confirm that the original is not identified as a dup but all the subsequent TFs with the same pipeline id (and not Done) are correctly identified.  Now comes the issue with creating the link.  Your solution, that provided me with an issue key would have worked easily to plug into the Link Issues action, but as you probably know it won't work with an id.  I am struggling with an easy way to grab the key for the issue that was identified as the original.  As mentioned, I have it's id but what would you suggest as the right way to correlate the id to the key, so that I can use it in the Link As Duplicate step?

Thanks again

[Bill Sheboy]

Good catch! 

How about an assumption... assume that the first issue added is the one you want.  Then you may change your lookupIssues JQL to sort by key, adding ... ORDER BY Key ASC

Then, just grab the first key: {{lookupIssues.first.key}}

[Ryan McBryde]

I applied that logic, sorting the original Lookup Issues so that the first result would be the "original" TF and then grabbed it's key with {{lookupIssues.first.key}} and assigned it to varFirstKey, which I was able to use in the Link step to create a Duplicates/Duplicated By link from the subsequent TFs that matched the search criteria to the "original" TF.  I did have to make one more change though.  The conditional step, checking to see if "{{lookupIssues.size|0}} gt 0" had to be changed to "{{lookupIssues.size|0}} gt 1" otherwise it executed the link logic and tried to link to itself, which failed.  My initial battery of tests, where I create an unique TF, and then clone it repeatedly, shows that the first one doesn't try to execute the duplicate logic b/c it realizes, by virtue of the {{lookupIssues.size|0}} that there is only one TF that matches the search criteria (itself) but each clone does get linked back to the "original" with the duplicates link, showing up in the "original" under the Duplicated By link type.  If you are interested, I will send you the complete rule logic.

Thanks again

[Bill Sheboy]

Yup (regarding the gt 0 versus 1 condition), and that is why I suggested excluding the trigger issue key from the lookupIssues JQL.

One other advantage of explicitly removing the trigger issue key: I read in the documentation or a post somewhere that, behind the scenes, the rule engine explicitly adds JQL to remove the trigger issue from branches and lookupIssue JQL to prevent a looping condition/runaway recursion error.  I have not consistently seen the issue excluded, so when needed I explicitly remove the trigger issue with JQL as a precaution.

If you can, please post an image of your final rule and then mark this question as answered.  That will help others looking for similar use cases in the future.  Thanks!

[Ryan McBryde]

Thanks Bill, I will re-check my JQL as I had thought I had excluded the original issue with the varFirstId.  Once I have it finalized I will post it as requested.

I really appreciate your help!