GitLab 8.12 Released with Cycle Analytics and Global Code Search

Sep 22, 2016

Whether you're working on a small or a large project, your tools should get out of your way and give you actionable feedback. This month, we're making sure GitLab does both better than ever.

GitLab 8.12 gives you feedback on how efficiently you actually work, helps you find code across the entire instance, makes your workflow much safer with a single click, and much more.

This month's Most Valuable Person (MVP) is James Munnelly for contributing the Kubernetes executor in the GitLab CI runner. This feature allows users to run CI tests in a Kubernetes cluster easily. James created this merge request over a year ago and showed great patience and persistence in the review process to see it to completion. Thanks, James!

Cycle Analytics

Reducing cycle time, the time it takes you to go from idea all the way to production, is the first principle of conversational development. The shorter the cycle time, the higher the efficiency of your team.

In order to make it possible to actually see what your cycle time is, we're introducing Cycle Analytics with GitLab 8.12.

Cycle Analytics in GitLab 8.12

Cycle Analytics tells you what your cycle time is and breaks it down into several steps, so you can quickly see where to improve and accurately predict when you're shipping something.

Find Cycle Analytics under Pipelines in all your projects.

Read more in the documentation for Cycle Analytics

Global Code Search (EE)

If you're running Elasticsearch on your GitLab Enterprise Edition instance, you will now be able to search through all code on the server!

Global code search in GitLab EE 8.12

Just use the search as before and GitLab will show you matching code from each project you have access to.

Note that this change requires that you rebuild your Elasticsearch index. See the upgrade barometer below for more information.

Merge Request Versions

When you're pushing more than a single commit to a merge request, it can be hard to view what changed between versions and the target branch.

Merge Request Versions in GitLab 8.12

With merge request versions you can view previous states of a merge request: compare between a previous commit and the target branch or even between versions, showing you what has changed between certain commits.

Read more in the documentation for Merge request revisions

Preventing Secrets in your repositories (EE)

It's a bad idea to commit secrets (such as keys and certificates) to your repositories: they'll be cloned to the machines of anyone that has access to the repository, only one of which has to be insecure for the information to be compromised.

Yet it happens quite easily. You write git commit -am 'quickfix' && git push and suddenly you've committed files that were meant to stay local!

GitLab now has a new push rule that will prevent commits with secrets from entering the repository. Just check the checkbox and GitLab will prevent common unsafe files such as .pem and .key from being committed.

Prevent secrets in your repo in GitLab EE 8.12

GitLab Enterprise Edition already had a feature that allows you to block files based on a regular expression, which you can leverage to block anything that we didn't think of. We also welcome suggestions and contributions to make this push rule even better.

Read more in the documentation on Push rules

Review Apps (Experimental)

We've made several additions to CI that, when combined, make some magic.

You can now use predefined CI variables as a name for environments. In addition, you can specify a URL for the environment configuration in your .gitlab-ci.yml file. Together, these features bring the first iteration of Review Apps.

Review apps are automatically-created environments that run your code for each branch. That means merge requests can be reviewed in a live-running environment. This was inspired by Heroku's Review Apps which itself was inspired by Fourchette.

These are small changes, but will make a huge impact on your development flow. Reviewing anything from performance to interface changes becomes much easier with a live environment.

Right now, Review Apps are labelled experimental, as the environments are not automatically destroyed when no longer necessary.

We're working on a blog post that will have an example.

SSH Authentication for LFS

If you're used to using SSH for your Git pushes, it was frustrating to still have to enter credentials whenever using LFS.

GitLab will now leverage your SSH key when using LFS, meaning that if you're using LFS while connecting through SSH, you no longer have to manually enter your credentials!

File transfers of LFS still happen over HTTP.

Toggle LFS

Git LFS (Large File Storage) is great, but as the name implies, it can have significant impact on your disk capacity. To make you feel a bit more secure about the LFS usage on your instance, you can now toggle LFS on instance, group, and project levels.

For instance, as a GitLab administrator, you can decide to turn off LFS for the entire instance, yet enable it for only a single group or project.

Limit Project Size (EE)

As an alternative to restricting LFS, you might just want to prevent projects from growing too large. You can now limit project size. This will take into account all repository data and LFS objects and stop any commits that will surpass that limit.

Limit project size in GitLab EE 8.12

You can set a global project limit and override that on group and project level, as an admin. This way, you can give particular projects extra space if necessary.

Read mote in the documentation about limiting the repository size

LDAP/Active Directory Improvements

This release contains several improvements to LDAP/Active Directory support for GitLab CE and EE:

Recover 2FA tokens through SSH

You can now recover your 2FA security codes using SSH. This should make it easier to recover your account, while still maintaining a level of security.

Read more in the documentation about recovering 2FA via SSH.

Filter Tags by Name

Want to quickly find a tag? That's much easier now with a handy little filter on top:

Filter tags by name in GitLab 8.12

API additions

We've expanded our API on several points with GitLab 8.12:

Improved GitHub Importer

Our GitHub importer keeps getting better, making it easier to migrate to GitLab. With GitLab 8.12, the importer will also copy release notes over to GitLab and now lets you choose the namespace you want your imported projects to go into.

Improved GitHub importer in GitLab 8.12

This should make it easier to migrate if you already have existing projects or prefer something different than GitLab's way of importing your projects.

Read more in the documentation about importing your repositories from GitHub.

Bulk update Merge Requests

You can now bulk update merge requests. This means you can set the status, assignee, milestone, label or subscription to multiple merge requests at once.

Bulk update Merge Requests in GitLab 8.12

Managing merge-request-heavy project should be a lot easier with this!


Build Grouping

If you have many similar builds, your pipeline graph becomes very long. We've made a small change to improve this: similar builds will now automatically group together.

Build grouping in GitLab 8.12

Expanded syntax highlighting

By upgrading to rouge 2.0.6, we've added syntax highlighting for JSX, Prometheus, mxml, 1c, turtle/trig, vhdl, and improved highlighting for Swift 3.

Sentry integration of Workhorse

GitLab-Workhorse can now report application errors to Sentry.

Read more in the GitLab-Workhorse docs

GitLab Runner 1.6

We are also releasing GitLab Runner 1.6 today. Some highlights:

To see the full list of all changes please read the Runner's CHANGELOG file.

GitLab Mattermost 3.4

GitLab 8.12 includes Mattermost 3.4, an open source Slack-alternative whose newest release offers 700 integrations with full Markdown support via Zapier, simplified bot and 3rd party authentication via OAuth2, and community integrations with Gitter, Heroku, Pivotal Tracker, Chef, Ansible and Yunohost.

Performance Improvements

Build permissions changes

GitLab 8.12 brings very important changes to build permissions.

We decided that build permissions should be tightly integrated with the permissions of the user triggering a build for the following reasons:

Now, any build that was triggered by the user is also signed with his permissions. When a user does git push or modifies files through the UI (the pusher), we will create a new Pipeline. The Pipeline will be owned by the pusher. So builds created in this pipeline will have the permissions of the pusher.

This allows us to make it easy to evaluate access for all dependent projects and container images that the pusher would have access too. The permission is granted only for the duration of the build. The access is revoked after the build is finished.

For detailed information about the build permissions and the changes it brings please see our documentation.

For the history and reasoning behind this change, you can read the full discussion in the issue.

Submodules in CI

Submodules were one of the reasons we redesigned the build permissions. Now using Submodules in your CI builds is easy.

To use submodules you have to use a .gitmodules file, which looks something like this:

[submodule "tools"]
    path = tools
    url =

To use the new build permissions for your submodules you have to convert your URLs to be relative:

[submodule "tools"]
    path = tools
    url = ../../group/tools.git

This will instruct Git to use the same credentials as it would for checking out your project sources.

The last step is to tell GitLab CI to fetch submodules:

  - git submodule update --init --recursive

You can read more about support for submodules in our documentation.

Other changes

This release has more improvements, including security fixes. Please check out the Changelog to see the all named changes.

Upgrade barometer

This release requires downtime due to foreign keys being added, column types being changed, and various columns being removed from some tables. The whole migration process could take up to 30 minutes for large instances. Smaller instances should expect a downtime of about 10-15 minutes.

(EE Only) Elasticsearch re-indexing

We changed the structure of Elasticsearch index for repositories, making use of Parent Child relationships. This requires a total rebuild of the ES index. Also Elasticsearch 2.3.x contains a bug that causes to fail all queries that use highlight feature and Parent Child relationship at once, so we recommend to use the version 2.4 and newer. After upgrading to GitLab 8.12, you will need to remove the old index and rebuild new index:

To remove the old index, call to Elasticsearch:

curl -XDELETE 'http://localhost:9200/gitlab-production/'

Then rebuild new indexes as described in Elasticsearch integration

Ruby Update

In our last release blog post we mentioned we'd be dropping Ruby 2.1.x support in GitLab 8.13, we no longer plan to stop supporting Ruby 2.1.x in the near future.

We still recommend you upgrade to Ruby 2.3 if you're running a source installation, as this is the same version that ships with our Omnibus package now.

Expanded usage data ping (EE)

In order to better understand the usage of GitLab by our customers, GitLab 8.12 EE now sends additional data along with its usage ping.

No information about the nature of the data, such as project names, comments or other content is transmitted. You can view the exact data that is sent in the admin settings, where this feature can also be disabled entirely.

See also the implementation in the merge request

GitLab-Workhorse Secret Key

GitLab-Workhorse now uses a secret key to sign certain messages sent to the GitLab Rails application. For now this is mostly a configuration sanity check; in future releases we want to add features to GitLab-Workhorse that require this secret key to establish trust.

If you use our Omnibus packages, or if you installed GitLab from source with our official init.d script, then this secret key will be generated and picked up automatically for you. If you use a custom init.d script or if you use packages not created by GitLab Inc. then you may have to set the -secretPath option on GitLab-Workhorse.


We assume you are upgrading from the latest version. If not, then also consult the upgrade barometers of any intermediate versions you are skipping. If you are upgrading from a GitLab version prior to 8.0 and you have CI enabled, you have to upgrade to GitLab 8.0 first.

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. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations file.


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


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.

Install GitLab on your own server in 2 minutes

Browse all posts

For the latest and most detailed news follow @gitlab on Twitter. Future blog posts suggestions.