Is it possible to return {{deployment}} values with {{{#lookupIssues}}?

[Ben Ikin]

Hi,

We currently have 2 automation rules that are triggering

The first is using the integration with Gitlab to transition Jira issues from 1 status to another upon a successful deployment into the 'test' environment group. This takes place overnight around 01:00 AM and is triggering on a per-issue basis. (more on that later). Inside this automation, a comment (or multiple) is added to the Jira issue which returns the following:

Deployed to Environment: {{deployment.environment}}
Deployment Name: {{deployment.name}}
Deployment State: {{deployment.state}}

Inside each Jira issue there could be 1-3 different comments with deployments if it is a multi-component issue.

The second is then running at 03:00 AM and using a lookup to return all jira issues in that particular status which then sends a webhook to create a confluence page using {{#lookupIssues}}. Inside that webhook we send a request which returns the following in a table format:

{{issueType.name}}, {{key}}, {{summary}}

These are both working fine independently.

What I'd like to do is link the events so that the 2nd automation rule can return the deployment information. Specifically {{deployment.environment}} and {{deployment.name}} that matches the specific (unique) issue returned from the {{#lookupIssues}}{{key}} which would returning the multiple {{deployment}} values associated if there are multiple.

I'd plan to add these as extra columns after {{summary}}.

As a bonus, I'd love to combine this into 1 automation where the 2nd trigger event can be when the LAST issue from the 1st automation rule finishes.

Happy to share screenshots of setup if that's helpful, but fair warning that the body of the Custom data webhook is full of formatting so not very readable.

Thanks in advance!

[Bill Sheboy · Accepted solution]

Hi @Ben Ikin 

First thing, I believe you will still need 2 rules.  As you noted, those DevOps triggers for rules often fire for each issue and so the rules cannot be combined.

Next, your first rule has access to the {{deployment}} smart value but the second rule does not: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-development/#--deployment--

And so your comment could be the bridge...

In your second rule, you could add a smart value, list filtering on the comments to find text matching your deployment comment(s), extract that, and use it in the custom data.  If you want to try that, here are some references:

• https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-text-fields/#match--

An alternative is to create a custom field specifically to store data from the {{deployment}} smart values (i.e., from rule 1), concatenating values as the rule triggers when multiple deployments happen.

Kind regards,
Bill

[Ben Ikin]

Thanks for the reply @Bill Sheboy

I had considered the custom fields but wanted to avoid using that method if it could be avoided, so I'm intrigued by the list filtering.

We don't currently separate out internal and external comments so I'd be searching for a particular string. Reading the documentation that seems like it should be OK but I seem to be struggling, maybe I need to take a break and come back to it later.

As there's a limit of 3, I'm working on the assumption that I can limit the filtering at the last 3 messages.  Example of the 3 possible variables in environments:

Environments: React / Java / Content (all followed by /test)
Name: Deployment ## (v#.#.##)

So I'd add 3 extra columns to the table (one for each environment)

In React I'd look to filter for the text "React" and return preferrably just the specific part of the message, but I could live with displaying the whole comment.

[Bill Sheboy]

Sounds good; if the variables are always updated for each environment you should always have the latest deployment.

With the match() function, rules use a regular expression.  Then you could use text functions after that to extract the data you need.

I have never heard of a limit on the return count for a list filter with rules, although I hypothesize it is 100 items.  To limit the actual results (e.g., to 3) the rule gets more complicated fast: there is an {{index}} for list items but I do not believe it cannot be queried directly.  A created variable and some shenanigans are required.

[Ben Ikin]

Ah that's good to know that match will find the latest one. Removes the need for a limit of 3.

Could it be as simple as something along these lines?

{{#issue.comments}}
{{ if({{issue.comments.match("React")}}, body) }}
{{/}}

[Bill Sheboy]

Please try this adjustment:

{{#issue.comments}}
{{#if(equals(body.match(".*(React).*"),"React"))}}{{body}}{{/}}{{^last}}, {{/}}
{{/}}

That will return any matches where "React" is in the body, delimited with a comma.  You could also use indexOf("React").gte(0) instead:

[Ben Ikin]

Response is 200 and posted but empty value is being returned in the table. Here's the code: (p.s. I'm running this with wider JQL to capture without waiting for next deployment)

{
"spaceId": "###",
"status": "current",
"title": "Release Note {{now.jqlDateTime}} ",
"parentId": "###",
"body": {
"representation": "storage",
"value": "<table data-table-width=\"1290\" data-layout=\"default\" ac:local-id=\"670eb159-d440-4d9d-9a9f-cf3cd151b258\"><colgroup><col style=\"width: 95.0px;\" /><col style=\"width: 101.0px;\" /><col style=\"width: 201.0px;\" /><col style=\"width: 893.0px;\" /><col style=\"width: 201.0px;\" /></colgroup>\n<tbody>\n<tr>\n<th>\n<p>Issue Type</p></th>\n<th>\n<p>JIRA ID</p></th>\n<th>\n<p>React Deployment</p></th>\n<th>\n<p>Jira Title</p></th>\n<th>\n<p>JIRA STATUS</p></th>\n</tr>\n{{#lookupIssues}}\n<tr>\n<td>\n<p>{{issueType.name}}</p></td>\n<td>\n<p><a href=\"{{url}}\">{{key}}</a></p></td>\n<td>\n<p>{{#issue.comments}}
{{#if(equals(body.match(".*(React).*"),"React"))}}{{body}}{{/}}{{^last}}, {{/}}
{{/}}</p></td>\n<td>\n<p>{{summary}}</p></td>\n<td>\n<p>{{status.name}}</p></td>\n</tr>\n{{/}}\n</tbody>\n</table>\n\n"
}
}

[Bill Sheboy]

Once you are inside of the scope of the Lookup Issues iterator, you may drop the issue prefix in front of {{#issue.comments}} to just {{#comments}}

[Ben Ikin]

Thanks @Bill Sheboy , I should've realised that so hoping a fresh start today helps!

Strangely, inside the "validate" part of the web request it generates a 200-success. But when I go to run with data it returns a 400-invalid-message-response. Any thoughts on this?

The only change was to remove the issue so it now reads {{#comments}}

[Bill Sheboy]

It is possible there is still a formatting error in there.  And there is one other possibility I have seen with web messages and JSON in rules: sometimes a timing problem prevents fully parsing before validation. (Although the 400 error would seem not to indicate that cause.)

Let's try this:

• Add a Create Variable action, with a variable named varMessage and a value of your entire expression
• Write that {{varMessage}} to the audit log, and pause to confirm the format is correct, adjusting as needed. 
  • I recommend copying the text from the audit log into the source editor of your choice, and reviewing to confirm syntax.
• If it still fails after any corrections, try using the variable as the only content in the message as {{varMessage}} and re-test.

[Ben Ikin]

Hi @Bill Sheboy 

Apologies for the delay, Christmas break and everything!

Thanks for your help so far, just to validate that I'm doing the right thing here, I have:

1. Created a variable action and named it varMessage.

2. Inside that variable I have entered: 

{{#issue.comments}}
{{#if(equals(body.match(".*(React).*"),"React"))}}{{body}}{{/}}{{^last}}, {{/}}
{{/}}

(I also tried with just {{#comments}}

3. I have created a step to add value to the audit log, using {{varMessage}} as the value.

4.  On reviewing the automation audit log, I am able to see the following:

I'm definitely missing something but struggling to identify what exactly as this stretches beyond my knowledge (and I'm happy to be learning!)

Could it be as a result of the rule returning more than 1x value to start with? I could adjust this down to specify a particular issue if that would be helpful.

[Bill Sheboy]

Hi, Ben...happy new year!

If you review that audit log, you will see a typo when you write {{varMessage}} as there is a square bracket in there.  Please correct that and then re-test.  Thanks!

[Ben Ikin]

Happy New Year!

I can't believe I didn't see that! DOH!

What is interesting with the results is that it now shows the correct comment with what we saw before:

Original comment as in JIRA

Extra Information for Logging:
Deployed to Environment: React/test
Deployment Name: Deployment 384 (v2.0.25@f5815c7e) to test
Deployment State: successful

Comment in Audit Log

, , , , , , , , , , , Extra Information for Logging: Deployed to Environment: React/test Deployment Name: Deployment 384 (v2.0.25@f5815c7e) to test Deployment State: successful, ,

So it adds the , characters. 

Separate to that I'm now facing a problem where the original API Post has stopped working (no change to automation rule configuration) but that doesn't appear to be blocking the troubleshooting at least.

[Bill Sheboy]

I think I see where the extra comma-spaces are from: the {{^last}} check is outside of the condition test.  Let's try moving that inside to see the impact:

{{#issue.comments}}
{{#if(equals(body.match(".*(React).*"),"React"))}}{{body}}{{^last}}, {{/}}{{/}}
{{/}}

If that does not work, the other alternative is to remove the values after the variable is created using the replace() function.

[Ben Ikin]

That's working Bill, thankyou! It does add a comma to the end, but I can remove that and I can also update the previous rule to shorten the information returned!

Only problem that I'm facing now is that the code previously working is returning a 404. I've gone back to a previous known good state and the same happens. I've even gone back to basics where no data is posted (simply create a page) and returns the same error. Have you seen this happen before? Seems to be being blocked now?

[Bill Sheboy]

I've seen that when my URL for the service is incorrect, or there is an outage on the receiving side.

I recommend diagnosing that symptom separately, such as calling the service with a mechanism outside of the automation rule.  That will help fault isolate it, and once it is working again, return to testing with the rule.

[Ben Ikin]

Yeah I'm pretty sure it's a block inside Jira -> Confluence.

The same request works external via Postman. But a request inside of Jira even as simple as below is now failing.

{
"spaceId": "#",
"status": "current",
"title": "Release Note {{now.jqlDateTime}}",
"parentId": "#",
"body": {
"representation": "storage",
"value": ""
}
}

[Bill Sheboy]

Did you try writing that request to the audit log to review it, ensuring it matches what you expected?

[Ben Ikin]

Yes, it still returns a 404 error in the POST but in the audit log I can see the data that I'd expect to see, including the searched for comments.

[Bill Sheboy]

Is there anything dynamic about your request URL, such as including smart values?  If so, have you validated it by writing the expression to the audit log prior to the Send Web Request action?

[Ben Ikin]

Nope nothing whatsoever. The configuration hasn't changed since we started, where it was working. The only parts that have changed are the custom data parts within the body of the request, and even going back to basics there doesn't resolve the issue. The same URL, headers and data work via Postman and leave the values written rather than return the values but I'd expect that. My next step will be to create it from fresh. 

Here's some screenshots of the configuration.

[Bill Sheboy]

I wonder if the call is encountering this defect, where using the content-type key is causing a duplicated header: https://jira.atlassian.com/browse/AUTO-98

Do you have logging on the receiving side to check the sent calls?