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
