JQL Branch not working-what is the "Issue"

[daniel_jones]

I am beat, cannot figure this out and I am sure I am missing something simple.

Long story short-I have a bunch of stuff above the image below and could not get my automation to update the item I wanted.  So I hard coded a JQL branch for an item and it still does not update it.  what am I doing wrong?

[Bill Sheboy · Accepted solution]

Hi @daniel_jones 

The rule uses the Incoming Webhook trigger, gathering issues from the request.  This means the trigger has issues, and...

A branch on JQL automagically excludes trigger issues from the JQL to prevent errors, such as runaway looping.  That is, behind the scenes, it adds this to the end of the JQL expression:

AND key != {{triggerIssue.key}}

There are two possible solutions (depending upon when you need conditions in a rule)...

• Need conditions: use branch on current issue.  For example:
  • trigger: incoming webhook, with issues
  • ...
  • branch: on current issue
    • condition: some condition
    • action: some action which acts on the "current" / trigger issue
  • ...more steps after the branch
• Do not need conditions: just perform the actions on the rule's main thread.  For example:
  • trigger: incoming webhook, with issues
  • ...
  • action: some action which acts on the trigger issue
  • ...

Kind regards,
Bill

[daniel_jones]

@Bill Sheboy the webhook does not include the issues, which is why I had to parse out the issue key from the webhook title.

[Bill Sheboy]

The image you show in this post linked below indicates the trigger uses "Gather issues from request":

https://community.atlassian.com/forums/Jira-questions/JQL-Branch-not-working-what-is-the-quot-Issue-quot/qaa-p/3144769#M1157184

[daniel_jones]

this is the body of the webhook data (maybe bitbucket is not set up right)

[Bill Sheboy]

This is the trigger option I noted based on your image:

Issues provided in the webhook HTTP post body

https://confluence.atlassian.com/automation/jira-automation-triggers-993924804.html#Jiraautomationtriggers-incomingwebhookIncomingwebhook

• If you are not using that option, the rule image you posted does not match...and my suggestion does not apply.  Thanks!
• If that option is used, and you are trying to branch on JQL to an issue from the trigger, that will not work.

[daniel_jones]

Thank you @Bill Sheboy I figured it was a brain cramp.  This gets me pointed in the right direction.  But to make sure-bitbucket sends a webhook which will trigger the automation rule.  However, then I should include the JQL to tell the rule which jira issues the rule should run on?

[Bill Sheboy]

Whatever comes into the trigger / rule, I was only noting the limitations of branching and the issues.  What do you want to do with the issues coming into the trigger: update them or just "read" them, such as for reporting elsewhere?

Perhaps if you explain what problem your rule is solving (i.e., why do this) that context will help the community offer better suggestions.  Thanks!

[daniel_jones]

@Bill Sheboy  I had put it in response to Dick, but will reiterate here.

We have JIRA integrated with Bitbucket.  Devs create a branch in BB per story in JIRA and we have a sub-task of each story to track the state of a "TAD" or Technical Design Document which are processed in Bitbucket (I know this is weird, but not my call).

So when the TAD is moved in BitBucket via a pull request, BB sends a webhook to JIRA (the body of which I posted an image of earlier)

I have need to extract the JIRA key from the webhook (which I have done via Regex), then find the TAD sub-task of that story (which I have also done via lookupIssues. 

Now I need to transition that sub-task depending on the status of the PR.  

But as you said earlier-since the webhook does not have an issue tied to it, I guess JIRA automation does not know which JIRA story/sub-task I want to update?

[Bill Sheboy]

Thanks, @daniel_jones -- Sorry, I should have read the other posts to catch up!

Once you extract the TAD subtask's issue key, I would expect a branch to that with JQL will work as long as the subtask issue is not also passed in the trigger.

And, as branches cannot contain an IF / ELSE block for the conditions on the PR status, you could invert that: use the IF / ELSE block for the conditions and then branch to the subtask for the update.  This will likely require repeating branch:

• ...
• action: lookup issues for the trigger issue with JQL to find its matching TAD subtask 
• smart values condition: to confirm one-and-only-one was found
  • first value: {{lookupIssues.size|0}}
  • condition: equals
  • second value: 1
• If / else block
  • smart values condition: to test your PR status
    • branch: on JQL to the TAD subtask key
      • action: transition the issue
• else / if
  • smart values condition: test another possible PR status
    • branch: on JQL to the TAD subtask key
      • action: transition the issue
• ...

Another way to do this is to use a conditional expression to determine the correct transition, and then perform the transition using the REST API endpoint.  This would eliminate all branches and conditions...although requires keeping the transition ID values in the rule synched with your workflow, required fields, etc.

[daniel_jones]

Thank you @Bill Sheboy this is getting me in the right direction for sure.  Been tied up but will try this and let you know.  I very much appreciate you and the others time and advice on this!!

[Rudy Holtkamp]

Hi @daniel_jones ,

Quick question, does the scope of your automation rule include the "GET" project?

[daniel_jones]

yes, it is not global but specific to the GET project

[Dick]

Hi @daniel_jones 

There's a couple of potential pitfalls in your automation:

• Branches fire in parallel, you do not know which will be executed first.
• The result of a branch should be reached in the branch, not in consecutive statements on "the main line of execution" (the vertical grey lines mean something here!)
• Your trigger has no singular issue at it's root-cause. So any reference in the main flow of the automation to the object "issue" is referring to something Jira Automation cannot handle. 
• Editing an issue in an automation (under Data Center) is editing in the database, not inside the automation objects and variables. If you need the results of such an edit, you need to execute a re-fetch issue action in your automation.

Kind regards,
Dick

[John Funk]

Hi Daniel,

Can you briefly describe exactly what you are trying to accomplish? 

And please share the entire rule so we can follow the flow (even it if takes multiple screenshots). 

[John Funk]

So, if the JQL is returning the right Sub-task, what id not working? It is not updating the Summary field as you expect? Can you share a screenshot with the details of the Edit to that field? 

[Dick]

Hi @daniel_jones 

{{issue.summary}} is a smart variable that hasn't been set using a create-variable step.

you can however use the field itself in the log by stripping the curly braces.

Kind regards,
Dick

[daniel_jones]

Thank you @Dick that helped a little, but see two images below.  First is the JQL validation-shows 1 item found.  Second is the result of the automation run-it says no issues found, stopping the rule?

[Dick]

Hi @daniel_jones 

This second question (and even follow ups on that) could be prevented if you shared your whole automation, including the per-step configurations.

Let's start by sharing the automation so that we can see what goes wrong?

Kind regards,
Dick

[daniel_jones]

@Dick and @John Funk  sure-I was trying to spare you from the long drama.

back story-we have integration with bitbucket, but we are on DataCenter so some of the neat stuff available on cloud is not an option.

We are wanting to update a sub-task in JIRA for tracking when a pull request is updated on a story.  When a pull request is created or updated in bitbucket, it pushes to the webhook in JIRA in the automation.

The first part of the automation is getting the story key from the webhook from bitbucket which works, then getting the tracking sub-task with lookupIssues, which also works.

I can get the automation to update the sub-task through many trials, but could not get anything to work.  So that is when I tried to just branch with the hard-coded value of the story in question. Which did NOT work.  You will see some audit actions where I was trying to debug.

[John Funk]

In the first JQL branch, try using:

issue in {{lookupIssues}}

Assuming the log before that branch is producing the right value? 

[daniel_jones]

Will try that @John Funk  and yes, the log produces the correct value.  But still wonder why the hard coded branch wont work 

[daniel_jones]

Here is the audit log from the last run

[Dick]

@daniel_jones

please provide all the configuration details of the individual steps of your automation as well.

[John Funk]

Okay so the first one is the parent that is getting selected in the lookupIssues, correct? 

And now you want to update the child Summary field value, is that correct? Or is there another field? And what is it you are wanting to update the field with? 

[daniel_jones]

@John Funk in the image of the audit I posted above.  The first log entry is the issue that had a PR against it and the log is of the regex I did to get the key.

The next two are from the lookupIssues which I used to get the correct sub-task of that story.  First one is the lookupIssues result, second is the variable I created from it (which I may not need)

What I want to eventually do is transition the sub-task based on the status of the PR, but started with a simple attempt to update the summary or add a comment.