GitLab is open source software to collaborate on code. Today we announce the release of a new version of GitLab Community Edition (CE) and GitLab Enterprise Edition (EE), with new features, usability and performance improvements, and bug fixes. The biggest new feature in Community Edition is the improved performance with large pushes. Other changes include the ability to edit a file in fullscreen (zen) mode, 'comment and close' button, wiki and snippets search and several API improvements.

In addition to the updates from Community Edition, GitLab Enterprise Edition allows assigning multiple LDAP groups to a single GitLab group.

This month's Most Valuable Person (MVP) is Robert Schilling for contributing zen mode, keyboard shortcuts and helping out on the issue tracker. Thanks Robert!

Updated 2014-09-23 10:00 CEST: Added a paragraph about omnibus-gitlab changes.

Improved performance on large pushes

Previously on a push that contained 1 thousand branches GitLab would create 1 thousand workers.

That would take some time to process during which other background tasks would be queued.

With the changes introduced in GitLab 7.3, a single push will only create a single worker which will handle all branches.

This allows other workers to be ready for new jobs and any long running workers can easily be stopped if necessary and making it less likely that GitLab slows down due to large pushes.

Keyboard shortcuts

Thanks to the contribution by Robert Schilling, keyboard shortcuts have been further improved with multiple shortcuts added. Navigation in GitLab just got easier!

Comment and close button

When commenting in an issue or merge request you can now easily close an issue while leaving the comment.

Zen (fullscreen) mode

Thanks to the contribution by Robert Schilling, you can now switch into a fullscreen mode to have more room to edit your issue, merge request or a comment.

New commits linked in Merge Request

When new commits are pushed to the existing Merge Request, they will be shown in the Merge Request timeline.

New API features

Users can now filter issues by state and labels when interacting with the API.

Thanks to sponsoring by O'Reilly Media it is now possible to sort merge requests in ascending or descending order for updated_at and created_at fields.

In addition you can also get more detailed information about merge requests and comments. You can read more about the GitLab API at doc.gitlab.com/ce/api.

Assigning multiple LDAP groups to a GitLab group (EE only feature)

Synchronizing with more than one LDAP group is now possible with GitLab 7.3 EE. You can link multiple LDAP groups to a single GitLab group and give them different permissions.

This makes our LDAP integration much more powerful and flexible.

Check the documentation for more information.

Security: connect to Redis via sockets

Redis is an in-memory database used by GitLab for asynchronous inter-process communication, cache storage and session storage. A standard Redis installation trusts all local TCP connections. This means that an attacker who can create a TCP connection originating on the GitLab server could be able to modify or read user session data. As a security measure against this risk we are changing the default settings for GitLab to connect to Redis via Unix domain sockets. This allows system administrators to limit Redis access to the git user using file/directory permissions.

What do you need to do to switch to Redis via sockets?

• Omnibus-gitlab users switch to sockets automatically when they upgrade to 7.3. Tip: if you changed your Redis port in gitlab.rb with redis['port'] = xxxx to avoid port conflicts, you can remove that line now.
• The required configuration changes for manual installations are described in the 7.3 upgrade guide.
• Instructions for cookbook-gitlab are still a work in progress.

Unix domain sockets only work for connections between local processes. If your Redis instance is running on another machine consider adding the firewall rules below. Alternatively, you could create an encrypted connection between the GitLab server and the Redis server using spiped.

# Iptables example for GitLab installations which cannot use sockets
# We assume the Redis server is listening at 192.168.99.1:6379

# Allow outgoing connections to 192.168.99.1:6379 for the git user.
# Disallow outgoing connections to 192.168.99.1:6379 for everybody else.
# Note: the order of these rules matters.
iptables -A OUTPUT -m owner --uid-owner git -p tcp -d 192.168.99.1 --dport 6379 -j ACCEPT
iptables -A OUTPUT -p tcp -d 192.168.99.1 --dport 6379 -j REJECT

We would like to thank Wyatt J. Brown for their responsible disclosure of this issue.

Omnibus-gitlab now supports non-bundled web servers

The omnibus-gitlab packages provide a bundled NGINX web server which acts as a reverse proxy for GitLab, and which also serves static files such as Javascript, CSS files and user uploads. Prior to omnibus-gitlab 7.3 it was not supported to use a web server other than the bundled NGINX, because the omnibus-gitlab directory layout prevented access to user uploads in the interest of security. In omnibus-gitlab 7.3 we have changed the omnibus-gitlab directory layout and permissions to allow for non-bundled web servers. As a side benefit, we now have a stronger privilege separation between NGINX and the GitLab Rails application.

To implement this change, omnibus-gitlab now creates a gitlab-www user which is intended to have read-only access to user uploads and read-write access to the Unicorn socket. For practical reasons, the socket used for communication between NGINX and Unicorn was moved from /var/opt/gitlab/gitlab-rails/tmp/sockets to /var/opt/gitlab/gitlab-rails/sockets. For more information about using a non-bundled web server with omnibus-gitlab, please see the omnibus-gitlab README.

In addition to the changes above, we changed the NGINX directory layout to avoid directories like /opt/gitlab/embedded/proxy_temp being created by NGINX. These temporary directories now get created in /var/opt/gitlab/nginx.

Other changes

Check out the Changelog to see these and additional changes.

Upgrade barometer

When upgrading to 7.3 there will be more time needed for migrations since there has been an important update to the GitLab structure, more specifically git hooks.

In addition to the hooks update there is a migration for the serialization of project services which loops through a lot of data. On installation with more than 10000 projects this migration alone took about 3 minutes.

** NOTE ** Users with large number of repositories (more than 1000) can expect prolonged downtime(up to 100 minutes depending on number or repositories) if upgrading from versions <= 7.2.1 . For that reason, we advise first upgrading to version 7.2.2, see this blogpost for detailed information

Users with smaller number of repositories (less than 1000) can safely upgrade directly to 7.3 expecting downtime similar to previous upgrades.

Other news

We just announced that WANdisco will incorporate GitLab in their globally distributed git product.

Installation

If you are setting up a new GitLab installation please see the installing GitLab page.

Updating

Upgrade instructions for omnibus-gitlab packages can be found in the omnibus-gitlab repository.

If you installed GitLab from source and you have version 6.4.2 or higher you can use the upgrade script. You have to update GitLab Shell to 2.0.0 manually, see point 3 of the upgrade guide.

If you still want to do it manually - see the Update Guide.

Enterprise Edition

The mentioned EE only features and things like LDAP group support can be found in GitLab Enterprise Edition. For a complete overview please have a look at the feature list of GitLab EE.

Access to GitLab Enterprise Edition is included with a subscription. No time to upgrade GitLab yourself? A subscription also entitles to our upgrade and installation services.