Development

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.

Comments (8 posted)

Quotes of the week

    from goto import with_goto

    @with_goto
    def range(start, stop):
        i = start
        result = []

        label .begin
        if i == stop:
            goto .end

        result.append(i)
        i += 1
        goto .begin

        label .end
        return result

Comments (13 posted)

Rust 1.3 is available

Version 1.3 of the Rust language has been released. The announcement listed API stabilization and increased performance work as the most notable changes. Specifically, there is a new substring-matching algorithm, a faster zero-filling method for initializing and resizing vectors, and speed-ups to the Read::read_to_end function. The release notes provide more detail. Also new in this release is the first edition of a new Rust programming guide, the Rustinomicon.

Comments (1 posted)

GeoClue 2.3.0 available

Version 2.3.0 of the GeoClue geolocation service has been released. The most notable change in this update is support for sharing and accessing GPS devices over a network connection. A proof-of-concept implementation of this feature is available in the Geoclue Share app for Android, which lets users relay GPS data from their device to a GNOME desktop system. Other new features include support for digital compasses and updated documentation.

Full Story (comments: 1)

Hamlib 3.0 released

Version 3.0 of the hamlib library for controlling amateur-radio equipment has been released. Changes include Android build-system support, extensive updates to the build system on desktop machines, updated support to several receivers and transceivers, and "history" features for several of the command-line utilities.

Comments (none posted)

Vala 0.30.0 released

Version 0.30.0 of the Vala compiler for the GObject type system has been released. This release updates the bindings to support the latest GObject type system used in GNOME 3.18.

Full Story (comments: none)

Firefox 41 released

Comments (3 posted)

nftables 0.5 released

Version 0.5 of nftables has been released. This update supports the 4.2 kernel, and adds several new features. Additions include the ability to concatenate multiple selectors in a single filtering rule, support for setting timeouts, and a dormant flag to quickly disable rulesets.

Full Story (comments: none)

GNOME 3.18

Full Story (comments: 19)

Development newsletters from the past week

• What's cooking in git.git (September 17)
• What's cooking in git.git (September 21)
• LLVM Weekly (September 21)
• Perl Weekly (September 20)
• PostgreSQL Weekly News (September 20)
• Python Weekly (September 17)
• Ruby Weekly (September 17)
• This Week in Rust (September 21)
• Wikimedia Tech News (September 21)

Comments (none posted)

Harrington: Wayland: Atomics Ahead!

Comments (5 posted)

Kuhn: Exercising Software Freedom in the Global Email System

At the Software Freedom Conservancy blog, Bradley Kuhn describes in detail the trouble that Conservancy has encountered by running its own, in-house mail server—specifically, the manual process required to get the server removed from automated blacklists maintained by large email services.

Comments (6 posted)