Trade Study Github vs. Gitlab
title: Trade Study: Github vs. Gitlab pageid: 50463027
Note
The Asterisk project moved to GitHub on April 29th 2023.
https://github.com/asterisk
The current Asterisk code base, and community services have been mostly self hosted and managed using various tool sets (Gerrit, Jenkins, Atlassian, etc...). While this has been fine we're always looking for ways to improve the project, and its workflows. As such the Asterisk project, and a number of its services will be moving to an internet hosted software development platform (e.g. Github or Gitlab). Doing so offers several advantages:
- Consolidates the code base and most services beneath one management application, which will make automation of processes between services much easier.
- Cloud hosts version control and other services removing the huge burden of having to self manage such things.
- Utilize an interface that is broadly used and hopefully more familiar to developers and other members of the community.
Moving will not be without effort though, and it's import to assess eligible products to ensure they can support the Asterisk project now, and in the future. Both Github and Gitlab offer similar services, and functionality1 ,2 (by tier1,2) that should suffice for what's needed. The following is a list of items that may be relevant to the hosting of the Asterisk project at one of the sites:
Github | Gitlab | |
---|---|---|
Deployment options | Cloud | Cloud and locally hosted |
Open source | No | Yes |
API | Yes | Yes |
Easy to understand documentation | Yes | Yes |
Public project benefits | Yes, public projects gain some extra benefits that are usually associated with paid tiers for private repos | Yes, being an open source project Asterisk should get full benefits of their ultimate tier, but need to qualify annually |
General limits | Actions, LFS | Various |
Repositories | ||
Public/Private | Unlimited (limited feature set for private) | Unlimited |
Collaborators | Unlimited | Unlimited |
Max size | < 5GB is recommended | 10GB |
Max file size | 100MB, however larger files can be tracked via their Large File Storage facility. | 5GB per push |
Permissions | Read, write, other roles (see also organizational roles) | Role based |
Statistics | Yes | Yes |
Collaborators/Users | ||
Max allowed | Unlimited | Unlimited |
Auth | SSH, 2FA, OAuth, SSO, and other integrations | SSH, 2FA, OAuth, SSO, and other integrations |
Crowd account preservation | No, a Github account will need to be created | No, a Gitlab account will need to be created |
CLA | Possibly, but will probably have to set something up using a Github workflow | No, will have to set something up with their automation tools (interesting post about why Gitlab moved away from CLAs) |
Issues | ||
Description templates | Yes | Yes |
Custom forms | Yes, in beta but available to public projects | No |
Confidential/Private | No, all issues are public | Yes |
Close via commit | Yes | Yes |
Canned responses | Yes | No |
Fixed version | Use milestones | Use milestones |
Other tags/labels | Yes | Yes, and also has scoped labels |
Code | ||
Review | Pull requests | Merge requests |
Require approval | Yes | Yes |
Require checks | Yes | Yes |
Cherry-pick via UI | No | Yes |
Private Repos/Forks | Yes, and forks for resolving security issues. | Yes, and should be used for confidential issues |
Security | ||
Issue | No private issues | Confidential issues |
Advisory | Yes | Reports, but there doesn't seem to be a way to edit it |
CVE integration | Yes | Yes |
Patch | Temporary private fork, or can use a private repo | Use private repo |
Continuous Integration | ||
Minutes | Seemingly unlimited for public repos, 2000 per month for private | 50,000 per month |
Storage | Seemingly unlimited for public repos (might be limited by max repo file storage), 500MB per month for private | 10GB |
Self hosting | Yes | Yes |
Triggers | Various builtin | API or webhook |
Parallel | Yes | Yes |
Workflow limits | 6 hours job execution time, 35 day workflow run, 1000 API requests an hour, 20 concurrent jobs, 500 runs queued a second, etc... | 1GB artifact size, 1000 per group/1000 per project runners, unlimited concurrent jobs, 25000 pipeline triggers, etc... |
Release Management | ||
Create | Yes | Yes |
Link to issues | Yes | Not yet |
Release notes | Automatic | Nothing automatic yet. Use the issue API and get issues assigned to a milestone |
Additional files | Yes can attach | Links available through UI, and API. |
Pre-release option | Yes | Naming only |
Forms | Yes | Yes |
Automation | Yes through actions, custom scripts or 3rd party tools | Yes through dev ops, custom scripts or 3rd party tools |
Documentation | ||
Wiki | Yes | Yes |
Pages | Yes | Yes |
One can see from the above that both platforms have the basic services and tools Asterisk needs to function as a successful open source project. They really only differ in a few minor areas. However, a decision has to be made and the Asterisk project has decided on:
Winner: Github¶
There are a few reasons why Github was chosen over Gitlab. One minor difference is that currently Github actions and workflows appear to be able to trigger off a greater number of built-in events vs. Gitlab automations. The latter seeming to require more custom tooling, and writing and maintaining our own scripts in order to achieve similar functionality.
There are probably a few other minor distinctions that swayed the decision, but there is at least one notable complication with Gitlab that made the choice easier. In order to use Gitlab's Ultimate tier the Asterisk project would need to qualify annually as an open source project. Note, the values listed in the table above assume such qualification. Otherwise we'd fall under their free tier, which only allows 5 users per namespace. In Gitlab a "User means each individual end-user (person or machine) of Customer and/or its Affiliates (including, without limitation, employees, agents, and consultants thereof) with access to the Licensed Materials hereunder" (see FAQ). Based on the current requirements it's "iffy" if Asterisk would qualify. Even if it did it's very possible Asterisk may not next time. The project just can't take the risk.