A look at GitLab 8.0

Version 8.0 of the GitLab code-hosting platform was released on September 22. After more than a year in development, the update brings several significant new features like continuous integration and large-file support, plus a reworked user interface. For free-software supporters, though, the best news may be that these new features are landing in the "community" edition of the product, not just in the proprietary "enterprise" version.

For those unfamiliar with it, the GitLab package implements a web front-end to a multi-user Git-repository-hosting service, complete with a variety of handy workflow tools to simplify managing an active project. The GitLab.com site, much like its main competitor GitHub, offers free-to-use accounts. Unlike GitHub, however, the GitLab code can be run on one's own server.

There have historically been two versions of the code (the aforementioned community and enterprise editions). While, in past releases, the differences between the two editions included some rather useful features (such as support in the web interface for creating Git hooks), the 8.0 release adds the same features to the community version as to the enterprise variant. There is still a delta between the feature sets, although one could perhaps argue that most of the enterprise features target users wanting to deploy GitLab internally on a corporate network (for example, LDAP and Kerberos support), which may not be as significant to the average user.

Regardless of where one comes down on that particular question, though, it is still possible to set up and run a functional GitLab instance on one's own machine. GitLab is written in Ruby, and there are several installation options: manual source installs, source installs using user-contributed installation scripts, and "Omnibus" installs from RPM or Debian packages.

The changelog for the 8.0 release is a long one, and some of the individual items can be deceptively brief. For example, one entry about halfway down the list says only "Remove satellites". But that change can have a significant impact for GitLab site administrators (particularly those running high-traffic servers). In previous editions, GitLab handled merge requests for a repository by maintaining a separate "satellite repository." This was done to allow GitLab to implement certain pre-receive hooks, but over time it became clear that maintaining the parallel repositories costs too much in terms of storage space and time. The 8.0 release does away with satellites, so every GitLab-managed repository is now half the size it was prior to 8.0, and many operations will be noticeably faster.

The banner feature for the new release, though, is integration with GitLab's continuous-integration service GitLab CI. Previously a standalone project only, GitLab CI can run automated builds on Linux, Windows, and Mac systems. Configuration for a repository requires only a YAML file, and the individual build runs are handled by runner processes (typically on virtual machines) that the user is responsible for configuring. Several implementations of the runner utility are provided, written in Go, Scala, and Node.js.

In addition to the "GitLab CI" branded option, though, GitLab 8.0 also supports integration with other, third-party CI tools. The first to be supported is Drone CI; others may come in the future. Whichever CI tool one uses, the integration with GitLab means that the status of the latest builds will be reported directly on the repository's GitLab project page, and a summary of all of a user's CI runs will be provided in the site dashboard page.

On the workflow side, 8.0 also integrates with Mattermost, a realtime team-communication web tool that mimics the popular "Slack" service. Mattermost is licensed under "Apache-wrapped AGPL" terms, which the project explains as meaning that the configuration and administration tools included in the codebase are released under the Apache 2.0 license via an explicit exception to the AGPL that governs everything else.

The new GitLab release also includes improved support for responding to issues via email. The primary method for handling issues over email is a general reply-by-email interface. Using this interface requires the availability of a mail provider that supports "sub-addressing" (e.g., the ability to handle actualusername+foo@example.com address extensions). The reply-by-email mechanism appends the information needed to correctly handle the message after the "+" in the GitLab server's address; that enables the server to function without requiring scores of individual mailboxes to be maintained on the mail server. Several open-source mail servers do support this feature.

In addition, the email messages sent by the GitLab server support Gmail's "action button" API, which lets the Gmail interface add a button to the message list view (for example, "View this on GitLab"). This API is entirely under Google's control, though it appears to have attracted at least some interest from open-source webmail projects: Roundcube has an open feature request asking to support the buttons.

A few other feature additions worthy of mention include a new Git HTTP transport server that runs in a separate process from the main GitLab application (thus making time-outs during periods of heavy load far less likely) and the use of SSL by default on web hooks.

Last but not least, the web interface has undergone a significant rewrite. There are functional additions, such as a web-based file uploader, and several new components, like public user-profile and group-profile pages. But the redesign also smooths over quite a few rough patches in the UI; the various controls and text fields are a lot more uniform in their size, layout, and look, which makes the web interface easier to use. There is also a better notification system that lets users choose events for which they want notifications, for each of their projects. The GitLab CI front end, which had previously featured an interface that was similar but not quite identical to that of the main web application, is now a precise match.

In July, we looked at another free-software Git-hosting package, Gogs. In comparison, GitLab is by far the more full-featured offering. That feature set comes at the cost of higher overhead: Gogs is a self-contained binary, while GitLab has a long list of dependencies that can be tricky to navigate when installing or even when updating. Thus, running an instance of GitLab can be a major undertaking, but it also fills a need that many organizations seem to be looking for: a self-hosted, multi-user repository site with an easy-to-use web front-end.