How to assign a Jira task to the triggering user on BitBucket commit

[Daniel Schealler]

I was trying to find out how to do this, and I found a lot of examples of people answering the question, but no answers.

Example

• https://community.atlassian.com/t5/Jira-questions/Is-it-possible-to-get-automations-to-assign-a-jira-issue-to-the/qaq-p/1398320

I worked out how to do it for my particular case, so sharing here for the next person who searches.

But before I do, could someone in the Atlassian support team please direct me to the latest ticket that relates to having the {{initiator.accountId}} smart value being populated in this scenario so I can vote for and watch it?

It's really really silly that this doesn't work out of the box between BitBucket Cloud and Jira Cloud. I really like how Atlassian products operate and integrate generally but my goodness some of the functionality that feels like it should just work out of the box doesn't and it makes it really hard to evangelize for you guys sometimes.

The entire point of the Atlassian ecosystem is all of your tools are supposed to just work nicely together right out of the box. I really shouldn't have had to work this hard to get BitBucket Cloud and Jira Cloud to talk nicely to each other.

Scenario

I have set up in a single organization a Jira Cloud project and a BitBucket Cloud repository that are tightly coupled - all issues for code changes to that repository go through that one Jira project.

All of my BitBucket users for that repository are Jira users for that project, and all users are using the same underlying Atlassian account in both Bitbucket and Jira.

Goal

The goal is to use Jira automation to detect whenever a developer makes a commit against a Jira issue that they have forgotten to assign to themselves. If the issue is unassigned, we want Jira automation to assign that issue to the user that triggered the commit.

Limitations

The main limitation for this solution is that you need either a workspace or a repository access token to make the call to BitBucket work.

The limitation on workspace level access tokens is that they are a premium feature.

The limitation on a repository level access token is it will limit you to only supporting one Bitbucket repository per rule, which requires you to adopt a model of one Bitbucket repository per Jira project and then re-creating your rule on each project.

Solution

We're going to set up a BitBucket REST API call inside our Jira Automation rule.

• Get a commit

This is a HTTP GET request with the following elements:

• URL: https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/commit/{commit}
• Accept Header: application/json
• Authentication: Bearer Token

Create Bearer Token

So to start with, we need to create our token. Go to your BitBucket repository and open the workspace settings. You can find this in the top-right under the cog/settings menu. In the left-hand navigation panel under SECURITY you should find the entry for Access tokens.

If you are setting up a repository level access token, you can find this in the same location under the repository settings.

From my testing the minimal permissions our token needs to make this work is read permission on repositories. So set that permission to enabled and give it a meaningful name. Mine is just Jira Automation Token but you can call it whatever makes you happy, I'm not the boss of you.

Be sure to save this token in a secure location as you will not be able to access it again.

Create Rule

Over in Jira automation, we're going to set up our rule.

Note that here I'm including all my logging. That's useful for when you're setting this up or diagnosing it, but feel free to remove the logging steps once you get everything up and running.

• When: Commit created
• Then: Add a value to the audit log
  • Initiator: {{initiator.displayName}} ({{initiator.accountId}})
• AND: Add a value to the audit log
  • Assignee: {{issue.assignee.displayName}}
• If: Issue is unassigned
• Then: Add value to the audit log
  • https://api.bitbucket.org/2.0/repositories/WORKSPACE/{{commit.repository}}/commit/{{commit.hash}}
  • Diagnostic logging for our web request below.
  • Replace WORKSPACE with the workspace in the url for your BitBucket repository.
• And: Send web request
  • Configuration guidance below
• And: Add value to the audit log
  • Response: {{webresponse.body}}
• And: Add value to the audit log
  • Author: {{webresponse.body.author.user.account_id}}
• And: Assign the issue to:
  • Assign the issue to: Smart Value
  • {{webresponse.body.author.user.account_id}}

Configuring the web request

This is the key part that makes everything work.

• Web request URL: https://api.bitbucket.org/2.0/repositories/WORKSPACE/{{commit.repository}}/commit/{{commit.hash}}
  • This is the same value we logged above for diagnostic purposes.
  • Replace WORKSPACE with the workspace in the url for your BitBucket repository.
• HTTP Method: GET
• Web request body: Empty
• Delay execution of subsequent rule actions until we've recieved a response for this web request: Enabled
• Continue running the rule even if the request response is not successful (i.e. non-200 response): Disabled
• Headers
  • Accept: application/json
  • Authorization: Bearer <TOKEN>

When setting up that authorization header, you want the key to be just the word Authorization, and then the value should be: Bearer TOKEN

If the repository access token you generated above was ABCD1234 then your value in that field would be: Bearer ABCD1234

Note also that you should make your Authorization token Hidden by enabling the Hidden checkbox to the right. This will make sure that nobody can swoop in later and steal your bearer token to do nefarious things with it.

How it all works

Once this is up and running and working, then under the hood this will now be calling the BitBucket REST API every time a BitBucket users pushes a commit that references a Jira ticket in that rule's project.

In the response body that comes back, there is an author object, that contains a user object, that contains an account_id property. The value of this property happens to be the Atlassian user that triggered the commit, reported from the BitBucket REST API.

This is the value that I wish was (and really already should be) available in the {{initiator.accountId}} smart value.

Because the user that did the commit is under the same Atlassian account as their user in the Jira project, this can then be passed in as the user in that final "Assign the issue to" action at the end.

And then, like magic... Everything just works.

Farewell and best wishes

Good luck and I hope this works out smoothly on your end!

Happy developing!