At work we have all infrastructure you can imagine. Today i’m going to talk about three pieces of them.
- Atlassian JIRA Cloud
- GitHub Enterprise
- Atlassian BitBucket Cloud
I was approached by a team that requested that we look into having BitBucket (In their case) drive the workflows of JIRA. If you are unfamiliar with JIRA it is a huge issue-tracker that you can customize beyond recognition. It is powerful, but is as a consequence quite complex. In this case the workflow consists of five states. TODO
, IN PROGRESS
, REVIEW
, TEST
and DONE
.
The requirement was as follows:
TODO => IN PROGRESS
- Given a JIRA issue
is in TODO
- When
a branch is created
, From JIRA or directly in GIT,that contains
a JIRA issue token - Then the JIRA issue is moved from TODO to IN PROGRESS
IN PROGRESS => REVIEW
- Given a JIRA issue
is in IN PROGRESS
- When
a Pull Request is created
onBitBucket or GitHub
thatcontains
a JIRA issue token - Then the JIRA issue
is moved from IN PROGRESS to REVIEW
IN REVIEW => IN PROGRESS
- Given a JIRA issue
is in in REVIEW
- When
a Pull Request is declined
on BitBucketor
GitHub thatcontains
a JIRA issue token - Then the JIRA issue
is moved from REVIEW to IN PROGRESS
IN REVIEW => TEST
- Given a JIRA issue
is in in REVIEW
- When
a Pull Request is approved
on BitBucketor
GitHub thatcontains
a JIRA issue token - Then the JIRA issue
is moved from REVIEW to DONE
- And the issue
assignment is set to unassigned
At first i was thinking that’s rather excessive to have such triggers. What i didn’t see is that this is exactly how the team already worked, in BitBucket. JIRA was just additional overhead to them. Sure, they created the branch from their issue. But after that they didn’t seem to want to bother with JIRA more than to move the cards just before their SCRUM standups. So it made sense all the sense in the world to add it. And it gave me a reason to have a closer look at our JIRA integration between GitHub Enterprise since it didn’t seem to parse any issues from it.
So here’s how i made it work, in case someone else out there has a similar use case.
Steps to achieve it
Become a JIRA admin
, because modifying workflows require administrator permissions (Luckily i have a close colleague who is the JIRA admin)- Setup Integration to BitBucket and GitHub enterprise from your JIRA
- Go to JIRA, Select
Settings
- Select
Projects
- Select
the name
of the project you want to add source triggers for - Select
Workflows
- Edit the
workflow
that is in use as list or diagram, diagram format is easiest - Drag transition lines from each workflow state according to the requirements and name them accordingly. I get five of them, one for each requirement. We should end up with something resembling the image below.
- Select a
transition
, a pop-up should appear describing triggers, conditions and post-functions of the transition.Click triggers (0) to edit
. - Select the relevant
source trigger
for that transition Repeat steps 9 to 11
until all transitions have a source trigger.- For the last requirement
REVIEW => TEST
we should add a post function that modifies the JIRA-issues field assigned to unassigned, it is added in the same way as source triggers but instead selectpost functions
. Publish the workflow
in order for the triggers to become activated
And you are all done!
You can check whether the triggers work by creating branches, commits and pull-requests that contain the jira issue and watch the activity tab on the JIRA issue to see that the source trigger actived!