Automating Jira Status Transitions by Integrating GitLab with GitLab for Jira Cloud

Introduction

In my previous article, I introduced a method to move statuses to specific locations when a GitLab merge request is merged.
While that was useful, its capabilities were limited and it was still far from the status automation I wanted to achieve.
However, after researching further and through some trial and error, I have succeeded in automating status transitions even at times other than when a merge occurs.
Therefore, this article is about automating status transitions.
The setup itself is simple and doesn't require any commands, so if you have similar requirements, please give it a try.

Preparation on the GitLab Side

First, create a group in GitLab.
This is because GitLab for Jira Cloud can only be linked with GitLab groups.
Select "Groups" from the GitLab sidebar menu and create a group.

The following items will be displayed; enter any name you like.
The group's visibility can be set to either private or public, as the integration works with both, so choose whichever you prefer.

Once the group is created, create any project within it.

Preparation on the JIRA Side

First, install the GitLab for Jira Cloud extension in JIRA.
Once the installation is complete, a "Get Started" button will appear; click it.
Then, a screen like the one below will appear; click "Sign in to GitLab."

The following screen asking for integration with GitLab will appear; click "Authorize."

Next, a screen with the message "No linked groups" will be displayed. Click the "Link group" button, select the group you created earlier from the list, and link it.
Once this is done, return to your JIRA project and create any issue.

I created the issue above for this example.
You should notice that items called "Development" and "Releases" are displayed in the issue details.

These are displayed because GitLab for Jira Cloud has been introduced.
In this guide, we will only use functions related to "Development," but since "Releases" also seems to have functionality, I hope to investigate it when I feel up to it later.
Also, as a note, even if "Development" and "Releases" are displayed, the link with GitLab might not be fully complete.
Therefore, it's safer to assume that seeing those items just means the installation is finished.
That completes the preparation for each environment.
Finally, let's set up the automation, which is the core of this article.

Setting up automation in JIRA

From here, we will actually use JIRA automation to perform status transitions.
The three automations we will set up this time are:

1. Move the status to "In Progress" when a branch is created.
2. Move the status to "In Review" when a merge request is created from a branch.
3. Move the status to "Done" when a merge request is merged.

Also, please note that the statuses I have configured in my JIRA are "BACKLOG", "In Progress", "In Review", and "Done".
Let's begin.

Setting to move status to "Done" when a merge request is merged

Go to your JIRA project and click the "Automation" button in the upper right.

The following menu will appear; click "Create automation".

There is an "Automation" item in the sidebar of the destination; click it.
There is a button "Create rule" in the upper right of the displayed screen; click it.
Then, as shown in the image, items to set the trigger for starting JIRA automation will be displayed.

Once you transition to the trigger selection screen, select "When branch created" in the red frame of the image.

After selecting the trigger, a screen where you can make additional settings will be displayed.
Since we want to move items whose status is "BACKLOG" this time, select "IF: Add condition".

Select "Issue fields condition" and set the values as shown in the image.

With this, we have ensured that only issues in the BACKLOG status are handled when the trigger occurs.
After saving, finally select "THEN: Add an action" and click "Transition issue".
Set the status to move to "In Progress" as follows and save.

Once the above is complete, give it an arbitrary name and enable it.
This completes the automation setup.
Now, let's check the operation.
In GitLab, create a branch with a name containing "MFMZ-11".
Then, the created branch and the issue will be linked as shown in the image.

Furthermore, you can confirm that the status moves automatically after a while.
This completes the setup for automatic status transition.
We will proceed with the remaining automations in the same way.

Setting to move status to "In Review" when a merge request is created from a branch

Trigger: When pull request created
Condition: Status equals "In Progress"

Action: Transition issue to "In Review"

The completed flow is as follows.

Setting to move status to "Done" when a merge request is merged

Trigger: When pull request merged
Condition: Status equals "In Review"
Action: Transition issue status to "Done".
The completed flow is as follows.

With this, each automation has been achieved.
By the way, conditions are not limited to status; you can also add issue type conditions as shown below, so you can separate the transition statuses for bug fixes and story tasks.

Challenges for Implementation

Up to this point, we have been able to automate status transitions in Jira.
I'd like to say let's implement it immediately, but there are some challenges.
One is that the integration with GitLab can only be done at the group level.
Therefore, all GitLab projects within the group are targeted, and if an issue identifier happens to match by chance, there is a possibility that an unintended Jira status might move.
Thus, when implementing it, you need the consent of not only your team but also everyone who has created projects in the target GitLab group.
However, since integration is possible even with GitLab subgroups, you can handle this by creating a subgroup and moving the necessary projects to that group.
That said, if there are many projects, the transfer is a hassle, and permission is required anyway.
By the way, the method for transferring a GitLab project to a subgroup is described in this Qiita article.
The second challenge is that you need at least project administrator privileges to set up automation.
Therefore, developers cannot easily set it up, and they may find themselves in a situation where they cannot even try it out.
Also, even if it is set up, the number of people who can manage it is limited, so the burden on specific individuals would increase.
For these reasons, it cannot be implemented easily, but it seems useful, so I'm thinking I'd like to try putting it in.

Conclusion

In this article, I described how to integrate JIRA and GitLab using GitLab for Jira Cloud to automatically transition statuses when a GitLab branch is created, a merge request is created, or a merge request is merged.
I had been feeling frustrated because it seemed possible but I couldn't figure it out, so I'm glad to have finally resolved it.
While this article only covered parts related to status transitions, there are many other automation settings available, so it might be fun to experiment with them.
Lastly, to vent a little again, articles about GitLab and JIRA integration often only contain text, which makes searching for information quite difficult.
Lately, I've been wishing people would include more screenshots.
Thank you for reading this far.

Reference Materials

Qiita article on integration between JIRA and GitHub
How to create a group in GitLab
A great community post that helped me realize the integration might fail if a GitLab group isn't created
Article on setting up automation in JIRA