nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Daniel Loewenstein_n3r4uw

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:

Accepted answers

All comments

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_n3r4uw

@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?

Mo Beigi_j358fk

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

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

Daniel Loewenstein_n3r4uw

@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.

I'll use Set Entity Property to store {{pullRequest.destinationBranch.name}} into the issue when the Pull Request Merged event is triggered
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_n3r4uw

@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!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

integration

automation

github

devops