Migrating from GitLab to GitHub｜Introducing the method from comparison to implementation

Kanno

Hello, I'm Sugano, a manager who loves development and loves ramen.

We have been using GitLab for a long time at Sun-El, but we have decided to migrate to GitHub.GitLab official websiteThis is because the Free plan has been limited to 5 users per namespace since October 19, 2022, as described in . It wasn't that I was dissatisfied with GitLab's functionality, but that I would still be using it if it hadn't been for this change. Like Docker, is it because GitLab went public? GitHub now has a private repository for free, but GitLab seems to have a stricter limit on the free tier. It seems that there are quite a lot of people who have been migrated with this change.

In this article, I will introduce what I learned after actually migrating to GitHub through the process of considering introduction. I hope it will be helpful for those who are in the middle of collecting information about migration and those who are considering which one to introduce.

About the situation of San-El before moving to GitHub and the target audience of this article

Before I get into the main topic, I would like to introduce the situation of San-El before the migration to GitHub.

• Been using GitLab for over 10 years
• GitLab has 7 engineers, 3 testers, and 3 project managers
• GitLab CI was used to build CI/CD
• GitHub has been used for project reasons such as consignment

Please note that this article does not explain the basics of Git or how to install node.js.

Flow from comparative examination of GitLab and GitHub to migration

Conclusion

For those who want a quick overview of the differences between GitLab and GitHub, here are my conclusions first.

• If the scale is 5 or less, GitLab is free, so you can use it if you like.
• GitHub if you can't put out $19/month per person. GitHub is free or $4/month per person
• $19/month out,Project management functionGitLab if you value
• If learning cost is important, GitHub. GitLab has fewer users (especially in Japan) than GitHub

Part 1 Considering whether to continue GitLab

If I wanted to continue using GitLab, I had three options:

1. Avoid 5 users per namespace
2. Upgrade to paid version
3. Migrate to the self-managed version where you set up your own server

The first is immediate rejection. Simply put, you can only use up to 5 people per project. Also, the management becomes quite complicated. Next is 2,planThere are only three, Free, Premium, and Ultimate, and Premium costs $19. Hey, I don't want to pay that amount. The rest is 3, but Sanel was originally using the Self-managed version. And two years ago. However, we had to migrate to the cloud version because we had to do not only the maintenance of the server but also the version upgrade ourselves, so I didn't feel like going back to the self-managed version.
So I decided to move from GitLab to GitHub.

Part 2 Consideration of GitHub pricing plans

GitHub has three plans, Free, Team, and Enterpise, and Team is 1 TP4T4 per user per month. It's pretty conscientious compared to GitHub. Enterpise is $21 so you can see how GitLab is expensive. In the first place, GitLab has quite a lot of project management functions, so I guess you shouldn't compare simple prices in the first place.

Compare each planOfficial SiteAnd leaving it to other sites, I think that the following two points are the points of whether or not Free is good.

1. I can't create an Organization token
2. I can't create a draft pull request
3. Can't set protected branch

Previously, there was a limit to Private Repositories, so when companies used it, the paid version (Team) was required, but now you can create unlimited Private Repositories even with the Free version. For this reason, if these two points are not a problem, I think that free is enough. Of course, I think it depends on where you place importance, but Sanel uses Notion for document management, so GitHub Wiki is unnecessary, and 2,000 minutes per month for GitHub Actions is enough.

It is quite inconvenient not to be able to use the Organization token of 1, and each project has to use the PAT (Personal Access Token) of the user in charge, but it is not good for management, so it is quite problematic. 2 and 3 are functions that can be used even in the free version of GitLab, so it is painful not to be able to use them. It would lead to operational accidents, so the scale of development, such as building CI/CD, is difficult with Free.

At San-El, we used the Free version for the time being and migrated to it, but since these two points are problems, we plan to switch to the Team version in the future.

Part 3 Impressions of actually migrating to GitHub

It was good point

Convenient Slack integration

For me, this is the best. You can also link with GitLab, but since there is no sign-in mechanism, the contents of Issues will not be displayed on Slack. In comparison, GitHub allows you to see the contents of issues from Slack, and you can also comment and close them. Also, if you sign in to GitHub from Slack, your GitHub account name will be converted to your Slack account name, so you will definitely be mentioned on Slack. GitLab was very inconvenient for this. It is assumed that the GitHub application can be installed in Slack, but in the target channel

/github login

All you have to do is enter and follow the instructions. Very easy.

GitHub Actions are quicker and easier

I think this depends on what you want to do with CI/CD, and it may be your preference, but I feel that GitHub Actions is easier to build than GitLabCI. I think this is largely due to the large number of users and the presence of MarketPlace. There are most common actions, and you can usually find how to do it by googling. GitLab CI feels like writing a script, but GitHub Actions feels like calling Action and executing it.

Convenient smartphone app

This is completely unexpected until you try it, but it is very convenient. Especially around authentication. Two-factor authentication is too troublesome without an app, so I can't let it go. Also, this is how to use it as a reviewer, but with the GitHub app, you can do reviews somehow. GitLab does not have an app in the first place, so you can only see it with a browser, but it was quite difficult to operate with a smartphone. I travel a lot, so it would be convenient to be able to review things on my smartphone in a hurry, but I gave up on GitLab. It's not as comfortable with the GitHub app, but you can review, comment, and merge normally.

bad point

As expected, the project management function is going up to GitLab.

Unable to group repositories

This is inconvenient. Especially if you want to separate the front end and back end repositories, but you want to manage them as one project. In that respect, GitLab was convenient because it was possible to group repositories and manage Issue Labels and Milestones in a shared manner. Also, since there is no grouping, it is not possible to have uniform labels for issues within the organization. You can set the default Label in the Organization settings, but this is just the default label when creating a repository, so if you want to add this Label for the entire organization, you can't add it all at once.

Board (Kanban) management is not possible with Issue alone

GitLab was able to set DueDates and Milestones in Issues themselves and manage them in the board view, but GitHub doesn't have that feature in Issues, it has a feature called Project. And it is a mechanism that can be managed by linking Project and Repository.
At first, I thought this would be useful because it allows you to bundle multiple repositories. However, when you actually use it, it's plain inconvenient. I think it's a problem with the UI structure, but GitHub also has an aspect that you can't manage boards on the issue screen, and you can't perform detailed operations on issues on the board screen. As a project manager, the feeling of detailed operation is stressful.

Actual migration method

From here, we will explain the actual migration work. It's easy to simply migrate the source code, but the problem is migrating Issues and Merge Requests. This migrationhttps://github.com/piceaTech/node-gitlab-2-githubuse a tool called The usage is described quite carefully in the README, but the main flow is as follows.

1. git clone node-gitlab-2-github
2. npm install
3. Mirror from GitLab repository to GitHub repository
4. Copy sample_settings.ts to stings.ts
5. edit settins.ts
6. npm run start

For details on each method, see the README, so I will omit them and explain the key points.

What this migration method does not address

This tool can migrate Issues and MergeRequests, but not all migrate perfectly. I think that all of them are acceptable, but if the following contents are not acceptable, this migration method cannot be used.

A merge request without a source branch cannot be migrated to a pull request

If there is a source branch, the merge request can be converted to a pull request, but if the source branch is set to be deleted when merged, a merge request without a source branch will be converted to an issue instead of a pull request. migrated. Once migrated, it will be automatically labeled as a gitlab merge request and added to the closed issue.

Issue and MergeRequest attachments cannot be migrated

Attached files can be uploaded to S3 with the option function of the tool, but since it does not replace the URL referring to the file, rather save the attached file from GitLab to S3 Just give it to me.

Issue Owner information cannot be inherited

The Issue Owner will be the execution account when migrating this time, to be precise, it will be the account name set in the script when executing, so I don't know who the issue issuer was when issued in GitLab. put away.

Issues with no target users cannot be migrated

If the user set as Assignee or Reviewer does not exist in GitHub, the Issue cannot be migrated and an error will occur. As much as possible, it is better to have accounts on the source GitLab and the destination GitHub.

1. Preparation

Get the GitHub accounts of all the users you want to migrate, and know their GitHub account IDs. You also need to create a GitHub Organization. It's not that difficult to create. Once you're ready, let's first create a repository to migrate to on GitHub. As long as you have a repository to migrate to, you can leave the repository settings as default for the time being. Next is mirroring to GitHub, but this isREADME PreliminariesJust do what the section says and you'll be fine.

2. Code fix

It's node-gitlab-2-github, but there were 3 problems with the code as it was, so I fixed it locally and dealt with it.

Add error output

As it is, I added the output because I do not know the cause when the attachment fails to upload.

       return Buffer.from(data, 'binary'); } catch (err) { + console.log(`err=${err}`) console.error(`Could not download attachment #${relurl}.`); return null;

What to do when Label is duplicated in Group Label and Project Label

It's not good that Labels are duplicated in the first place, but unfortunately Group Label and Project Label were duplicated. Perhaps it was created by mistake and left unnoticed, but in this case an error occurs and the transfer cannot be performed. So I added code to force deduplication.

       if (settings.conversion.useLowerCaseLabels) { labels = labels.map((el: string) => el.toLowerCase()); } + labels = Array.from(new Set(labels)) }

Correspondence when Japanese is included in the attached file

I think this is normal. Especially for screenshots attached to bug issues, the default file name includes Japanese. For this reason, I modified it to URL encode.

   async getAttachment(relurl: string) { try { - const attachmentUrl = this.host + '/' + this.projectPath + relurl; + const attachmentUrl = encodeURI(this.host + '/' + this.projectPath + relurl); const data = (

3. Edit and run settings.ts

How to editWhere to find info for the settings.ts in the READMEIt is described in detail where the information is written. The location of the AccessToken is also carefully explained, so I don't think you will get lost. Once you're ready, run npm run start and you'll see the output below.

$ npm run start > gitlab-2-github@0.1.5 start > node node_modules/ts-node/dist/bin.js ./src/index.ts ================ =================== Transferring Description ============================= ===== ================================== Transferring Milestones ========= ========================= Creating: Initial development completed Creating: Delivery completed ================ ================== Transferring Labels ============================== ==== Creating: doing Creating: improvement Creating: in review Creating: tested Creating: testing Creating: to do Already exists: bug Creating: discussion Already exists: documentation Already exists: duplicate ~~ ================================== Transferring Releases ============ ====================== Transferring 0 releases ========================= ========= Transferring Issues ================================== Transferring 141 issues. Migrating issue #1 ('account list')... Migrating issue comments... ...Done creating comments (migrated 11 comments, skipped 3 comments) ...DONE migrating issue #1. ~~~ DONE creating issues. Statistics: Total nr. of issues: 141 Nr. of used placeholder issues: 0 Nr. of used replacement issues: 0 Nr. of issue migration fails: 0 ========== ======================== Transferring Merge Requests ======================= =========== Transferring 218 merge requests Creating pull request: !1 - Pull request #1 (source branch 'sugano/basic_structure' does not exist => cannot migrate pull request, creating an issue instead Migrating pull request comments... ...Done creating comments (migrated 24 comments, skipped 3 comments) request #218 (source branch 'sugano/update_perpage' does not exist => cannot migrate pull request, creating an issue instead. Migrating pull request comments... ...Done creating comments (migrated 3 comments, skipped 0 comments) Transfer complete!

By the way, it takes a long time to run. Although it depends on the number of issues and pull requests, it took about an hour for a total of 500 cases.

4. Rewrite from GitLabCI to GItHub Actions

Well, the repository migration is now complete. It's not a big deal if it ends with the above. The most cumbersome to migrate is CI/CD migration.

For the time being, GitHub describes the migration method from GitLab Ci to GitHub Actions.

https://docs.github.com/ja/actions/migrating-to-github-actions/migrating-from-gitlab-cicd-to-github-actions

However, in my opinion, it is better to learn how to write GitHubActions and rewrite from scratch instead of simply converting the description method. GitLab CI and GitHub Actions have different ways of thinking and styles, so if you write in a migration style, you will be dragged by the style of GitLab and the goodness of GitHub Actions will fade.

If you have written GitLab CI, you can apply GitHub Actions relatively easily if you keep the following in mind.

summary

Kanno

How was it? For those who are thinking about migrating from GitLab, and those who are wondering which one to migrate from Bitbucket, etc., I would appreciate it if you could help me.

Personally, I've been using GitLab for a long time, so I'm used to it, and I'm attached to it. At San-El, we are based in rural areas, but we would like to continue to devote ourselves to not lower our antennae for technology.

Finally, we summarize our recommendations for each case.