GitLab rivals… Winter is here
Here in Linagora, we believe in OpenSource. We know that the OpenSource community attracts motivated developers who are often very disciplined. These developers know that their code represent their CV, hence they try to write it in the most elegant way possible. Linagora believes in OpenSource cause it knows that all users of OpenSource products have access to the source code, and hence often suggest both bug fixes and enhancements to the source code. Consequently, the quality of the software produced by the OpenSource community sometimes exceeds that produced by purely commercial organizations. It is worth noting that OpenSource does not mean freemium. These concepts are totally orthogonal. I am not going to compare these concepts here. If you are interested, please refer here for more details.
Migrating our repositories from Bitbucket to GitLab was so easy thanks to Git. However, migrating our issues (a.k.a., tickets) from JIRA to GitLab was not so obvious. In fact, there are several alternative solutions to integrate JIRA as a plugin inside GitLab so as to continue using JIRA along with GitLab. However, our main goal was to completely leverage GitLab as our only OpenSource development tool.
If you want to know how to migrate your JIRA issues into GitLab, then you are on the right medium article. Once you read it, you will discover that it is really so easy to do the migration from JIRA to GitLab. Yes as you can see, the winter is coming to GitLab rivals, cause every thing is possible with GitLab.
Migrating JIRA issues into GitLab Issues
- API calls:
To perform REST API cals, you can use your own preferred library. For me, I will use axios, which is my preferred promise based HTTP client for the browser and node.js. You can simply install it locally by doing:
npm install axios
- JIRA side:
Before requesting the endpoints provided by JIRA, we need to gather the following information:
Now, we need to call two endpoints call during the migration process. The first endpoint is to get all JIRA issues:
The second endpoint is to get the attachements and the comments related to a given issue:
- GitLab side:
As for JIRA, we need to gather some information before starting sending REST requests:
Each JIRA issue has several fields which represent JIRA users, e.g., assignee and reporter. Once migrating to GitLab we should try to link these users to GitLab users (if they already exists on GitLab). However, if the user is not a GitLab user, then we have to leverage the GITLAB_TOKEN (line 18 in the last gist). That is, if the user does not exist on GitLab, then the identity of the user who is doing the migration will be used instead.
To search all GitLab users we need to send the following REST call:
And now, we can find the corresponding GitLab user for each JIRA user by doing:
It is worth noting that JIRA and GitHub issues are different in nature, so you need to migrate one type of issue to another. After searching all JIRA issues and JIRA attachments and comments, we can now transfer them into GitLab issues by doing the following mapping:
Now our GitLab issue is created, all what we need to do is to post it:
As you can see, migrating your JIRA tickets to GitLab is all about some REST API calls. As a developer, I think that you do such REST API calls every day. So we really do not need to stuck with JIRA nor to add it as a plugin to GitLab.
If you think that this article helps you discovering something interesting that you feel you want to do everyday, so please do not hesitate and join us. We are looking for new talents. For more information, you can have a look on our Job site.