Aug 22, 2015 - GitLab  

GitLab 7.14 released with improved syntax highlighting and Variables in CI

Learn more about GitLab Release 7.14 for GitLab Community Edition (CE) and Enterprise Edition (EE)

Today we're pleased to announce version 7.14 of GitLab Community Edition (CE), GitLab Enterprise Edition (EE), and GitLab CI.

Whereas next month's release, version 8.0, promises many new and exciting features, our focus for 7.14 has been on fixing bugs and improving performance and usability. Many of these bug fixes were contributed by this month's MVP Stan Hu, bringing his total number of awards to four. Thank you and congratulations, Stan!

To celebrate Stan's hat-trick + 1 (4 MVP titles in the 7.x major release) GitLab is giving him an extra weekend in Amsterdam after he joins us with the rest of the core team for our summit during OSCON.

Beta: support for long git push/pull over HTTPS

GitLab supports two protocols for pushing and fetching Git data from Git clients such as the git command and GUI clients: SSH and HTTPS. Traditionally, the SSH protocol has been the best and sometimes only way to do long-running (i.e., slow or large) push/pull operations from Git on your computer to a GitLab server. One of the reasons for this is that Unicorn, the Ruby web application server used by GitLab, is not designed to handle many concurrent long-running requests. With Unicorn, long git pushes/pull will often fail (due to a timeout) after hogging precious resources (Unicorn workers) for a long time.

To address this problem, we created gitlab-git-http-server, a stand-alone web server written in Go to take over (most of) the job of serving Git HTTP requests. We use Nginx to route HTTP requests either to Unicorn (normal requests) or gitlab-git-http-server (Git clients).

In the GitLab 7.14 Omnibus packages, gitlab-git-http-server is included but disabled by default. In GitLab 8.0 we will deprecate the old Git HTTP server in GitLab (grack).

If you want to start using gitlab-git-http-server ahead of the 8.0 release, as we will on gitlab.com, you can add the following settings to /etc/gitlab/gitlab.rb:

gitlab_rails['env'] = {
  'GITLAB_GRACK_AUTH_ONLY' => '1'
}

gitlab_git_http_server['enable'] = true

Run gitlab-ctl reconfigure and gitlab-ctl restart unicorn after updating your gitlab.rb file.

Improved syntax highlighting

GitLab has implemented the popular Rouge library as our syntax highlighter of choice. Rouge has support for 72 languages and does a great job of properly highlighting your files in GitLab.

Show who edited a discussion note

When a note is edited by someone other than its original author, such as a project administrator, we now show who it was along with the time.

Note Modification

Better LDAP group management (GitLab EE)

Our Enterprise Edition users managing their GitLab groups with LDAP will be glad to hear that we've improved the way they're handled in GitLab. Groups synced with LDAP can no longer be brought out of sync by group changes made via GitLab's interface.

YAML Variables (GitLab CI)

Now you can define variables in your .gitlab-ci.yml file that will be passed to your CI builds, allowing you to fine-tune linked services by, for example, supplying a custom database name.

See the Docker documentation for configuring services and the CI documentation for more information about variables.

Build Triggers API (GitLab CI)

As part of our ongoing effort to improve support for dependent builds, we've introduced Build Triggers that can be used to force a rebuild of a specific branch or tag via API call. To use Build Triggers, go to your project's Triggers page where you'll find a custom link that can be called from other services.

Build Triggers can also accept custom variables that can be used to customize the behavior of the build scripts.

Build Triggers

Application Settings interface (GitLab CI)

We're now surfacing application settings in the web interface of GitLab CI, furthering our goal of making all of the GitLab applications as easy to configure as possible.

Application Settings

Better support for skipped builds

GitLab CI and its integration with GitLab CE and EE now have improved support for builds skipped via the [ci skip] commit message tag.

CI Skipped

Bundling of Mattermost now, possibly RocketChat in the future

In this release we've bundled Mattermost, an open source on-premises Slack alternative. More information can be found in the announcement. The current release is in alpha state, so we can't guarantee it will be upgradable and recommend against exposing it to the public Internet. Activation instructions can be found in the Omnibus documentation for GitLab Mattermost.

After we announced the Mattermost integration we saw that RocketChat is also interested in shipping with the GitLab Omnibus packages. We didn't consider RocketChat since they run on top of MongoDB while we prefer PostgreSQL, but it seems that elephants don't fly, most of the time. RocketChat is committed to becoming compatible with the Omnibus packages.

We're thinking of shipping RocketChat with the Omnibus packages of GitLab 8.1 (although earlier, later, and not at all are also options). Having two different Slack alternatives in the GitLab packages is not ideal. But both projects are moving quickly and we find it hard to pick a winner now. Consider the alpha state a warning that we don't guarantee that both will ship with GitLab forever.

Other changes

This release has more improvements, including security fixes. Please view the Changelog to see the full list of changes.

Upgrade barometer

This release's migrations are minor. If you are on GitLab 7.13 CE or EE you can upgrade to 7.14 while staying online.

The GitLab CI upgrade will require downtime. Coming from 7.13 the database migrations in GitLab CI will be fast but they cannot be performed online.

Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how "big" or "small" the upgrade is. The behaviour can be changed by adding a /etc/gitlab/skip-auto-migrations file.

Reminder: Ruby (MRI) 2.0.x no longer supported

As of the previous release (7.13), we have dropped support for the 2.0.x versions of Ruby (MRI). We support Ruby (MRI) 2.1.x and recommend using 2.1.6.


Installation

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

Updating

Check out our update page.

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 you to our upgrade and installation services.


We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.

Share your feedback

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source