How GitLab is Doing CI Right

There is now a large selection of Continuous Integration services, both in the cloud and self-hosted. The idea is simple and powerful: whenever new code is pushed to a repository, a series of predefined tasks is run to check whether the code works correctly. This allows the developers to get notified immediately if their changes broke something. However, while this functionality is extremely useful, it is limited by the fact that code hosting and continuous integration are separate services. Notably, when you open a list of commits in GitHub, you can’t see which commits passed their Jenkins tests and which failed. Conversely, it’s not always easy to see which versions and which repositories were involved in a certain Jenkins build. Both of these lookups would help immensely when determining which change broke the build.

Except for GitLab and GitLab CI. Since the release of GitLab 8.0 with integrated CI in 2015, we now have the exact view I was talking about.

GitLab commit list with CI
It’s the commit history of a project, and the CI results are shown next to each commit. I can see exactly at which point something went wrong, and as you can see I was able to fix it immediately.

Similarly, for each build run, GitLab shows exactly which code version was used for it, including the commit ID and branch name. I don’t have to worry about each failed build, since it’s clear which faulires come from development branches and which from master or release branches.

GitLab build history with branch and commit information

As you can see in the second image, this very website is generated on GitLab with the Hugo site generator. It is deployed to GitLab pages with a two-step CI process (first is build, second is deploy), and the page clearly shows the build status of each commit.

Of course, not everything is rosy with GitLab CI. For one, there is no support for multi-configuration (matrix) builds, which is something I need for another project. However, this is a missing feature that can be added in a future version, and can be done manually until then. The integrated view, on the other hand, cannot just be added to an existing CI solution without deep integration with a code hosting service, or vice versa. So I believe GitLab is approaching CI from the right direction, providing excellent build status views with very little setup. I can only hope that their offering will expand in the future, and/or that other providers will follow suit.

comments powered by Disqus