Automation not working with Advanced compare condition

[Boyd K]

Jira Data Center 9.0.0 (self-managed/hosted) with Git Integration for Jira to integration with Gitlab 14.10 (self-managed/hosted). Our environment is closed and classified without not connection to the outside.

Trying to set up Automation to transition a Jira Issue when a Pull Request Merged if the "{{pullRequest.destinationBranch.name}} equals CM_test" condition is met. But, the Audit log states that the condition is not met. Not sure if my syntax is incorrect.

[Boyd K · Accepted solution]

The automation rule now works after I switched to "contains" instead of "equals" in my condition.

[Boyd K]

.

[Stefan Salzl]

Hi @Boyd K ,

Please try the following smart value:

{{pullRequest.destinationBranch}}

Furthermore for debugging you could add a "Log action" to write result of your smart value to your audit log to check if it´s correct.

In case this doesn´t help please provide some details (eg. a screenshot of your automation rule and the audit log).

Best
Stefan

[Boyd K]

I tried it with pullRequest.destination and the condition was not met.  I added the Log actions to print out the pullRequest.destinationBranch and  pullRequest.destinationBranch.name and the both list CM_test.  Do I need quote marks around CM_test?

I wish I could simply attach a screenshot but I have no connection to the server which is on a closed classified system.  So here is what the log shows:

Pull request trigger

  Issues found for the pull request

    id=10: [ISSUE-22]

Log action

  Log

    Branch is CM_test

Log action

  Log

    Branch name is CM_test

Advanced compare condition

  The following issues did not match the condition:

    ISSUE-22

Here is the Advanced compare condition I currently have:

If: Compare two values

  Check if:

    {{pullRequest.destinationBranch}}

    equals CM_test

[Boyd K]

I believe I understand why the condition that is not being satisfied which results in the rule not executing.

The workflow has a validator on that transition.  Thus, with that validator not satisfied, the rule would not execute.

Does that sound like the possible cause?  If so, we would need to rethink that transition in the workflow.

[Boyd K]

Well, the issue persists even after removing the validator from the workflow transition.  In fact, I changed the action of the automation rule to set a field rather that execute a status transition.  Still the condition of the automation rule is not met, though the Log action show the values that the condition should have been met.  I have no idea what to do.   Is the Advanced compare condition the correct check to use when checking pullRequest.destinationBranch or should I be using JQL condition or Related issues condition?

[Stefan Salzl]

Ok. Let´s take one step back and wrap this up.

What exactly is the ende2end use case you are trying to solve? Could you please describe your situation/problem in a functional way from the very beginning to the expected outcome?

Furhtermore one technical question:
As far as I know the functionality of "linking jira issues to branches/commits" the branch name/commit message needs to start with/contain the issue key. As from your previous posts your branch name is CM test. Is this branch linked to a jira issue?

Thanks in advance.

Best
Stefan

[Boyd K]

Here is the initial goal: Upon a merge request completed on the CM_test branch, execute the CM_Ready transition of the associated Jira Issue.

Now, the goal is for the merge request to trigger the setting of two fields in the associated Jira issue: Target Branch set to CM_test and CM Ready set to Yes.

Steps:

1. From the Jira issue, developer creates a branch off of CM_test.  The name of the branch includes the issue key.

2. In Gitlab on the newly-created branch, developer commits updates/changes to the file(s) ensuring the Jira issue key is in the commit message.

3. From the Jira issue, developer creates a merge request from the newly-created branch to the CM_test branch ensuring the Jira issue key is in the title of the merge request.

4. In Gitlab, the merge request is completed by the reviewer to the CM_test.

5. Upon the completion of that merge to CM_test, the hope is that the Jira issue would have its CM_Ready transition executed.

Notes:

- Both developer and reviewer are users with accounts for Jira and Gitlab.

- Integration between Jira and Gitlab works for at least steps 1 through 4.

- Set the following Automation Rule:

  > Pull Request Merge

  > Then: Add value to the audit log "Merged to the {{pullRequest.destinationBranch.name}} branch

  > If: Compare two values, Checks if {{pullRequest.destinationBranch.name}} equals CM_test

  > Then: Edit issue fields, Target Branch

  > And: Edit issue fields, CM Ready

  > And: Add value to the audit Log, Issue {{source-key}} / {{issue.key}} merged to {{pullRequest.destinationBranch.name}}

- Here is what the Audit log says:

   > Pull request trigger, Issues found for the pull request id=3 : [ISSUE-21]

   > Log action, Log, Merged to the CM_test branch

   > Advanced compare condition, The following issues did not match the condition: ISSUE-21

[Stefan Salzl]

Hi @Boyd K 

I tried to reproduce your situation but the following automation rule worked fine in my system (jira cloud with github):

Could you find any differences regarding your and mine automation rule?

Best
Stefan

[Boyd K]

I am integrated with Gitlab instead of Github.

Also, my destination branch was CM_test instead of CM-test.

But in any case, I worked with the vendor GitKraken since it was their app Git Integration for Jira which I was using.

It now works after I switched to "contains" instead of "equals" in my condition.