Issue in Next-Gen project - Automation to transition issue status not working

[Daniel Loewenstein]

This isn't as much of a question as it is a request for help in solving an issue. Anyway, Below has information I'm. I'd love for any information as to whether this is known existing issue vs. a potential issue with my setup. For the latter, could use direction on how to troubleshoot. 

Overview

I'm trying to get issues in my next-gen project to automatically advance by using GitHub integration. e.g. Smart Commits + the Jira Github Application (e.g. not using the DVCS connector).

I believe that I have all the proper setup in place but the status of my Jira issue is not updating when I take actions in Github ... or rather ... it the status of the card isn't staying updated. From looking at the "changelog" information returned when all call a GET for the issue via the JIRA REST API, I can see that the status is advancing and then seems to immediately get reverted milliseconds later to the previous status. The advancing of the status and the reversion to the prior status are associated with an"Automation for Jira" account.

Details

Here's workflow that I have setup for my Next-Gen project:

In my next-gen project I have a project-level automation rules setup to transition:

• When Branch created
• When commit added
• When PR created
• When PR merged

Here's example of the setup for PR created:

In my card, I'm able to see that the automations are getting triggered:

 

Also, the Automation also shows "success" in the history log: 

Here's information that I'm seeing in the "changelog" portion of JSON when I call .../rest/api/2/issue/{{issue-key}}?expand=changelog

JSON details:

{
"id": "11134",
"author": {
"self": "https://medcurio.atlassian.net/rest/api/2/user?accountId=557058%3Af58131cb-b67d-43c7-b30d-6b58d40bd077",
"accountId": "557058:f58131cb-b67d-43c7-b30d-6b58d40bd077",
"avatarUrls": {
"48x48": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"24x24": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"16x16": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"32x32": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png"
},
"displayName": "Automation for Jira",
"active": true,
"timeZone": "America/Denver",
"accountType": "app"
},
"created": "2020-11-23T17:16:59.423-0700",
"items": [
{
"field": "status",
"fieldtype": "jira",
"fieldId": "status",
"from": "10004",
"fromString": "Acceptance Testing",
"to": "10001",
"toString": "In Progress"
}
],
"historyMetadata": {}
},
{
"id": "11133",
"author": {
"self": "https://medcurio.atlassian.net/rest/api/2/user?accountId=557058%3Af58131cb-b67d-43c7-b30d-6b58d40bd077",
"accountId": "557058:f58131cb-b67d-43c7-b30d-6b58d40bd077",
"avatarUrls": {
"48x48": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"24x24": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"16x16": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png",
"32x32": "https://secure.gravatar.com/avatar/600529a9c8bfef89daa848e6db28ed2d?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FAJ-0.png"
},
"displayName": "Automation for Jira",
"active": true,
"timeZone": "America/Denver",
"accountType": "app"
},
"created": "2020-11-23T17:16:59.319-0700",
"items": [
{
"field": "status",
"fieldtype": "jira",
"fieldId": "status",
"from": "10001",
"fromString": "In Progress",
"to": "10004",
"toString": "Acceptance Testing"
}
],
"historyMetadata": {}
},

[Mo Beigi]

Hi @Daniel Loewenstein ,

From my understanding, you have two active transition automation rules.
One which fires on a pull request merge.
The other which fires on a commit created.

And as you have noticed, when a PR is merged both rules are executed causing the unwanted double transition behaviour.

You can use Smart Values to perform the addition exclusion checks you need:
https://support.atlassian.com/jira-software-cloud/docs/smart-values-development/

For your Commit Created rule, you will need to use a condition like the Advanced compare condition and compare {{branch.name}} with the name of your main branch (i.e. master) to prevent execution. Alternatively, you could prevent execution if {{commit.isMergeCommit}} is true but this may also stop the rule from running in other scenarios (when a merge commit is made).

Hopefully this solves your issue.

Try it out and let me know how you go!

Regards,
Mo

[Daniel Loewenstein]

@Mo Beigi Thanks for sending along the link on the development-related smart values. I hadn't seen these. {{commit.isMergeCommit}} seemed promising. For some reason, however, it doesn't appear to get set to True when the Commit Created event it triggered by Github merging a Pull Request.

Here's information from audit trail:

• 
• 

I think, however, that I can use similar setup as the setup outlined in the article that Bill linked.

1. I'll use Set Entity Property to store {{pullRequest.destinationBranch.name}} into the issue when the Pull Request Merged event is triggered
2. I'll update my Commit Created to check if PR destination branch is set to "master" so that it doesn't move the issue status back to In Progress.

I tried testing things out but there's an ongoing incident right now where Jira Cloud users are experiencing issues with data propagation delays and failures. I'll update this thread once I can confirm the results of my testing.

[Daniel Loewenstein]

@Mo Beigi and/or @Bill Sheboy I seem to have all of the requisite setup in place but things don't seem to be working : (. Calling it an evening for now but including setup below in case you see something obvious that I'm missing. Thanks in advance for any thoughts/advice.

The sequence that is causing problems is 1. PR merges in Github and automation rule sets status to done (desired outcome). 2. Commit to master branch in Github registers and the "Commit rule" automation sets the status back to In Progress. To avoid this, I'm attempting to make the "Commit rule" smart enough to "see" that the commit is occurring on the master branch in order to short-circuit the action in the rule form executing.

In my "PR Merge" rule, I save off the destination branch of the PR:

I can tell this works by the audit log information and by invoking a GET request to the REST API: base_url/issue/{{issue key}}/properties/destinationBranchName

Then, in the "commit rule" I have the following: 

I can see in the audit log that {{issue.properties.destinationBranchName}} is returning the full URL of the destination branch. 

This includes "master" so it seems as though the "Does not contain" comparison operator simply isn't working ... 

[Bill Sheboy]

Hi @Daniel Loewenstein 

It may help if you post the complete rule that you believe to be failing, with your included log statements and audit log output.  That might reveal if this is a rule processing/logic issue rather than the condition not working as expected.

Thanks!

[Mo Beigi]

Hi @Daniel Loewenstein ,

First of all sorry for the late response, I did not get a notification.

Unfortunately, it looks like the isMergeCommit flag we need is always false for the Github provider. This issue is being publicly tracked here:
https://github.com/integrations/jira/issues/345

Your attempted workaround of storing the pullRequest destination branch name as an issue field is quite interesting and should have worked in theory. I'm not too sure why that approach is failing. Could you post your audit log when attempting that to see the order of rule executions?

Thanks!

[Daniel Loewenstein]

Hi @Mo Beigi Lost track of this one but coming back to it now. 

Here's sequence of the two automations that are firing: 

Here's audit log for 2439243209 (PR Merged):

Given that the audit log is sorted in descending order by date time and that the id is less than the "Commit created" audit log entry, I assume that this is occurring first. 

When this rule runs, the following occurs: 

1. The {{pullRequest.destinationBranch.name}} value is present.

2. It is successfully getting saved into a custom property titled "destinationBranchName"

3. In the e-mail I can see that {{issue.properties.destinationBranchName}} successfully works to as a reference to get me the branch.

In audit log entry 2439243212, I see the following: 

In the rule, the text that immediately follows "destinationBranchName:" is {{issue.properties.destinationBranchName}}.

It appears that even though {{issue.properties.destinationBranchName}} works when setup in the context of sending smart values in an e-mail, it is not working to grab the custom property when the commit rule is being evaluated. 

It seems like there are one of two issues: 

A. There's a race condition. e.g. The evaluation of the "commit" rule is checking for {{issue.properties.destinationBranchName}} before the "merge" rule has saved it off. The e-mail content works b/c steps evaluate sequentially with the rule. 

B. The smart value syntax works differently when used in sending e-mail contents vs. evaluating rules. 

Thoughts or ideas? e.g. is there some way to introduce a 1 second paus within a rule evaluation to confirm theory A?

[Bill Sheboy]

Hi @Daniel Loewenstein 

I have definitely encountered race conditions in rules, due to the asynchronous processing.  The rule structure can impact what matters and when, especially with branches and conditions.  Would you please provide an image of your complete rule?  That may provide some context for ideas.

Regarding the smart value syntax working differently at different times, that seems less likely.  You could rule that out by either logging repeatedly to watch for issues or saving the value to a created variable and then using that variable for the rest of the rule. (I believe the created variables change values to plain text.)

__Bill

[Daniel Loewenstein]

@Bill Sheboy 

Here's the full rule for the commit trigger: 

Here's what I have in the e-mail for the "PR Merged" rule:

{{issue.properties.destinationBranchName}} works just fine in this context.

[Bill Sheboy]

Thanks for that information... Timing problems can occur in single rules also, such as the create issue trigger, where all of the issue data may not be available when the event is caught.  The work-around for that is to immediately re-fetch.  This seems different...

You have two rules, attempting to trigger in close timing proximity, correct?

When you expect one rule to trigger another, based upon the actions it takes, ensure that the dependent (second) rule has the option set in the rule details to allow that: Allow rule trigger.  Otherwise the rule engine seems to have run-away prevention to protect against accidental timing/looping problems.  So the second rule could fire inconsistently.

One approach for dependent rules is to create a completely independent trigger condition, like a semaphore design.  With this approach the first rule does its work and then causes the condition that will trigger later rules.  Maybe map this out on a timeline of when you expect the events to occur to help decide how to modify the rules.

[Bill Sheboy]

Hi @Daniel Loewenstein -- Welcome to the Atlassian Community!

Thanks for all the details on the issue you are seeing.  You have provided a summary of your automation rules and one example rule, so I wonder if...

• the asynchronous nature of the rule execution is causing multiple rules to fire, and so changing status backwards in your flow (noting the workflow with Any Status entry points)
• some rules are not firing as you expect due to rapid changes being detected as a run-away loop, and so the rule engine stops them firing

How to get more information:

• pause and map out on paper how you believe your rules should trigger
• add logging to your rules to confirm the decision points are happening as you expect and that the smart values contain what you expect
• run a happy path test and confirm what you see in the logs

And if you haven't watched it already, this webinar from Atlassian shows examples of wiring up the DevOps triggers and smart values:

https://www.atlassian.com/webinars/software/how-to-supercharge-your-automation-in-jira-cloud

Best regards,

Bill

[Daniel Loewenstein]

@Bill Sheboy Thanks for the pointers. I think I figured things out. As you suspected, more than one trigger was firing.

One potential challenge is that it appears that when Github integration hits the "Pull Request Merged" trigger it also hits the "Commit Created" trigger.

If I had a rule that could check the branch of where the commit was occurring then I could filter this out to avoid the card being set to "Done" then immediately set back to "In Progress". 

I'm not seeing a "Condition" in rule builder that would allow checking the branch of the commit. Have you heard of any previous requests to be able to check the branch of the commit to control what action occurs? Is this something Jira would consider for future development?

[Bill Sheboy]

Hi @Daniel Loewenstein 

No, I have not seen that condition test, and...

Here is a article on how to capture the some of the development data as entity properties when the initial triggers occur.  (Some of that data is *only* available when the trigger occurs, so preserving it is useful later.) 

Using entity properties, you may be able to do what you are asking by later comparing to what is stored in the properties.

https://community.atlassian.com/t5/Jira-Software-articles/Access-to-development-wise-smart-values-in-Jira-Automation/ba-p/1349839