Choose GitLab for your next open source project

原文:https://b.agilob.net/choose-gitlab-for-your-next-project/

GitLab.com is a competitor of GIthub. It’s a service provider for git-based source code repositories that offers much more than it’s bigger brother. In this post I will try to convince you to try it out for your next project.

GitLab is not only a simple git hosting; its features impact the whole development process, the way of contributing to a project, executing and running tests, protecting source code from changes, more and more.

1. Private repositories

Many newcomers to the industry struggle to find git hosting for their projects where they learn how to write good code, they experiment and don’t want to share source code, because it is low quality. On Github all you can get is one private repository, on GitLab… they don’t count. Personally I have several private repositories. I host there my projects from studies, some experiments with new languages as well as assignments in LaTeX. I used GitLab with  my friends to share revision notes before finals. I created a new repository, invited them to my projects as administrators  and we could work together on the same project while no one else could see it. GitLab goes a step ahead of this, so that you can create 3 different types of repositories:

2. Site personalisation

One of its features making GitLab even more user friendly is that you can setup what information you want to see when visiting a project or main page:

Even better, you can choose which style you want to see source code and commit diffs in!

Do I have to tell you, it’s good for people with vision problems?

3. GitLab CI

GitLab offer continuous integration service (GitLab CI) without runners for most languages. GitLab provides its own CI runner and service that is very easy to integrate into your project. Installation instructions are also very easy to follow. You will find it in project settings. This feature has its advantages and disadvantages compared to Github Travis:

+ You can test your project on multiple platforms. If your code is platform dependent, uses some kernel-API, requires some setup before tests are run, or your customer requires your software to work on Java6, Java7 and Java8, you can just setup 3 runners with 3 different environments and run tests on them. I use it to test my code on older versions of Qt on BSD and newer versions of Qt on Linux.
+ You don’t have to deal with old Ubuntu packages if you relay on newer version of a library. We had this problem in qTox where we were forced to turn off Travis because of outdated sqlcipher library
+ You can use your machines, so you control everything. You can write a script to automatically make a deploy using your known ssh key.

– You need to provide your own machine that will run tests for you
– You are responsible for security of that machine and code you are running there
It’s not everything. GitLab integrates very nicely with other CIs:

• Atlassian Bamboo CI
• Jenkins
• Drone CI
• JetBrains TeamCity CI

Probably some more… You can enable integration with CIs and other services under your project Settings -> Services

No matter which CI integration you choose, you will get the same view in the UI and each pushed commit will trigger CI build. It works a bit differently than naked Jenkins which you have to configure to start builds every x-hours/minutes. GitLab will automatically trigger build on configured CI when ^HEAD of a branch changes. That means, you can make 10 local commits and push to remote once, so that code will be build once in the CI, or you can push each commit to build it 10 times. Functionality covers also ignoring CI. When you make change in documentation or formatting, you don’t want to waste time, so you can add ‘[skip ci]’ text at the end of the commit message!

It integrates that nicely, that you can forget that you have Jenkins:

Or maybe you’re interested in success rate of your builds? Sure, you can see it on a graph.

4. Supporting open source culture

A couple of years ago SourceForge was one of the biggest supporters of OSS. You could host there your source code, huge binary files like ISO images. The problem with SF was that… it was proprietary itself and a lot of people didn’t and still don’t trust it. When git was created, there was a market gap for more secure, more open source friendly hosting. Github was created to fill the gap, but again… they claim to be open source friendly and at the same time they do not publish their code. Github is too expensive for self hosted solutions. They concentrate probably most on open source projects right now. I know business is business, but let’s take a look at how GitLab does it.

GitLab offers community edition source code on MIT license; they host enterprise edition for you for free on gitlab.com. GitLab encourages project managers to specify license, publish and update changelog files and contribution guide. You’re not forced to do it, but it’s a really good practice in open source communities do to it. All of those you can see from the main page of a project:

If you want to, you can host GitLab CE on your server for free. It’s much easier than you think and it runs everything from Raspberry PI to clusters with 30 000 users. Find out more here.

5. Merge requests approves and functionality

When your project becomes more popular, it requires more and more people to look after it. You need to be careful about changes in source code and its quality. You need more eyes on the source code… or you can just automate it. In project settings you can select a list of trusted people who can approve merge requests and number of required approvals to merge changes. It’s enough to get a few of trusted developers who care about your project, they can vote if diff is good quality and can be merged to main code base.

It offers another good function, if you reviewed changes, but CI is still running, you can enable ‘auto-merge’. Merge request will be merged after CI reports green!
6. Issues

Yes, GitLab has issues. Quite serious. It’s obvious, issue can belong to milestone, can have a few labels and be assigned to a user. On GitLab an issue can also have:

• weight – how important for developers a change is
• votes – users can vote on issues important for them! This is what I call contribution to open source communities!
• labels – I didn’t find out how this can be useful… but at least it’s not disturbing. You can give yourself a medal for reporting an issue… I guess

Now when someone opens me a new issue, they see content of the template in text area :) Isn’t that great? How much time would it save you if you had it 10 years ago? Why don’t you have it yet?

7. Templates!

How often someone opens new issue for a topic that was discussed many times, or users didn’t bother to search for duplicates, or they didn’t try to walk around an issue, or “DOESNT WORK”, or didn’t provide enough details… or… you what. GitLab let’s you specify template of issue and merge request. You can at least try forcing users to deliver you information you need before they click submit. It makes your life easier, saves you a lot of time, helps producing better quality reports and you don’t have to ask the same questions over and over again to every reporter.

8. Milestones are interesting things in GitLab

They work a bit like sprint boards… You can see open, ongoing and completed issues and progress of the whole milestone. It’s a bit like poor man’s JIRA.

We’re getting closer to the end of the list of things I like in GitLab, but remember this list is not complete and you will find more features like protected branches, handy way of creating git hooks to prevent committing .exe, .id, .bin, .o files to your repository, limiting max. file size, simple code review editor for diffs.

GitLab also promotes their fork of git-flow called GitLab flow that similarly as GitHub-flow fixes some issues with bare git-flow, take a read. Some other features that you might want to use in your company are LDAP support, repository mirroring.

9. Groups and permissions

As I mentioned in 1. you can create a group. A group is a list of people who share repositories which can be public, internal or private. Groups are always public, but members of groups have permissions. This systems is more complex, so I will refer you to the official documentation where it’s explained better than I could have explained it.

10. Do you value linear git history?

They solved it on merge request level. You can decide what method will be used to add new commits to your branch. If you don’t mind non-linear history, default settings are good; if you want to avoid merge commits, you can force contributors to rebase their commits on ^HEAD of your branch before merging. This way you can also improve code quality, even if there is no git conflict, there might be a change in source code that breaks tests. Learn more about linear history here.

11. Puzzles aren’t complete

There are some things that GitLab is missing. Many people say it’s web-based notifications. Currently only email-based is supported and more feature complete Android client. Can you live without that?