GitLab 8.12 released

Regardless of the scale of your project, your toolkit should:

but. to be comfortable in work
b. give useful feedback.

This month, GitLab is better for each of these items. GitLab 8.12 gives you feedback on the effectiveness of your work, helps you find the right code across the entire code base, allows you to secure your workflow with just one click and does much more.

This month’s MVP ( Most Valuable Person ) is James Munnelly: he integrated Kubernetes into GitLab CI . This feature makes it easy to run CI tests on a Kubernetes cluster. James opened this merzh-request about a year ago, and then patiently and persistently refined it according to the results of the review.

Thanks, James!

Software Development Cycle Analytics

The first principle of conversational development (convdev) is to reduce the time of the software development cycle, that is, the time for which the idea is implemented and released on production. The shorter the cycle time, the higher the efficiency of your team.

In GitLab 8.12, we implemented Cycle Analytics - a tool that shows the average cycle time in your team.

Cycle Analytics shows you the length of your development cycle, breaking it up into separate stages, so that you can see where improvements are possible, and you can accurately predict development times.

The Cycle Analytics page is located on the Pipelines tab of each project.

Learn more about Cycle Analytics

Global Code Search (EE)

If your instance of GitLab Enterprise Edition is configured with Elasticsearch, you will be available to search by code for all projects at once.

Use the search in the same way you did it before; only now GitLab will show you the results from all the projects to which you have access.

Note that this feature requires rebuilding the Elasticsearch index.
More information about this can be found in the “Barometer of Updates” section below.

Merge Requests Versions

If you add new commits to a merge request, it is very difficult to see the diff between one of the previous commits and the target branch.

With the help of tracking the versions of merge-requests you can see the previous states of the merge-request and compare any of the previous commits with the target branch or with another commit.

More information about the versions of Merge-Requests

Protection against the publication of sensitive information (EE)

Committing sensitive information such as keys and certificates is a very, very bad mistake. This data will get to anyone who can clone the repository, and in order to compromise information, one leak will suffice.

Unfortunately, this happens quite often.

For example, you write git commit -am'' && git push , and then you discover that you commit something or not.

In GitLab, there is a new check for push (push rule), which blocks commits with sensitive information. Just check the appropriate box, and GitLab will not allow to commit unsafe files, such as .pem and .key .

In GitLab EE, even before, it was possible to block files by a regular expression. You can use it to adjust the blocking of what is not included in our filter.

Learn more about push tests.

Review Apps (experimental feature)

We made a few changes to the GitLab CI. Together they create a bit of magic.

Now you can set the environment names in the CI variables. You can also specify the URL for the environment configuration in the .gitlab-ci.yml . Together, these two capabilities form the basis of the first iteration of the Review Apps.

Review apps are automatically created environments in which code from each branch is deployed. This means that now each merge-requester is automatically assigned a working environment.

The idea of ​​this feature was taken from Heroku Review Apps , and Heroku borrowed it from Fourchette .

These small innovations can have a significant impact on your workflow. Reviewing any aspect of the application — from performance to the user interface — becomes easier when there is a working environment.

At this point, the Review Apps feature is considered experimental because environments are not automatically destroyed yet when they are no longer needed.

We are currently writing a new article with Review Apps examples.

Log in to LFS over SSH

If you are accustomed to pushing through SSH, then entering your username and password every time you use LFS is probably a little frustrating.

GitLab now uses your SSH key when using LFS. That is, if you use LFS, connecting via SSH, you no longer have to manually enter data to identify

LFS file transfer is still done via HTTP.

Enable and disable LFS

Git LFS (Large File Storage) is good, but using this feature, as the name implies, may require a lot of disk space. To make you less worried about wasting disk space, you can turn LFS on and off for the entire GitLab instance, for a group of projects, or for a specific project.

Project Size Limit (EE)

In addition to limiting the size of the LFS, you can now limit the maximum size of projects. The restriction applies to all repository data and LFS objects and will stop any commit that exceeds the specified limit.

The administrator can set a global limit and override it at the group and project level. This way you can allocate extra space to specific projects.

More information in the documentation on limiting the size of the repository.

LDAP / Active Directory enhancements

This release adds some improvements in LDAP / Active Directory support for GitLab CE and EE:

• CE / EE - Request only user / group LDAP attributes that GitLab (CE 6187 and EE 712 ) will need, reducing the amount of data transferred between GitLab and the LDAP / Active Directory server. It also reduces the amount of memory used by objects inside GitLab.
• EE - Accelerating nested group selections and user requests that are quenched (for large groups) ( 719 )
• EE - Added 'Sync now' option to team member page if LDAP group links are present ( 704 )

Recovering two-factor authentication tokens via SSH

Now you can recover your two-factor authentication codes using SSH. Recover your account if it is stolen has become easier, while the overall level of system security has not decreased.

See the two-factor authentication recovery documentation over SSH for more details.

Tag filter by name

Want to quickly find a tag? Use for this new convenient filter at the top of the page:

API add-ons

In GitLab 8.12, we expanded our API:

• Now you can set the request_access_enabled parameter for groups and projects
• Added API calls to notification_settings
• Added API BroadcastMessage
• Now you can load into specific namespaces through the API
• Ability to enable / disable access requests for groups and projects
• Added web_url field to tickets, merge requests and snippets (functionality implemented by members of our community)
• Returning sha and merge_commit_sha in an API request for merge requests. (functionality implemented by members of our communities)
• Recognition of the privacy mark of the ticket (functionality implemented by members of our communities)
• Added project setting only_allow_merge_if_build_succeeds . (functionality implemented by members of our communities)
• Added an API call to check your .gitlab-ci.yml file for syntactic correctness (lint) (functionality implemented by members of our communities)
• Added an API to display manual actions in the Deployment Environments (Environments) and Deployments (Deployments) sections.

Improved import tool from GitHub

The import tool with GitHub is getting better and better, simplifying the migration to GitLab. In GitLab 8.12, the import tool will also copy release notes into GitLab, and also allow you to choose the namespace into which projects are imported.

This should ease the migration process if you already have projects in GitLab, or if you need something that is different from the default import behavior in GitLab.

For details, see the documentation on importing repositories from GitHub .

Mass Merge Requests Management

Now you can edit several merge requests at once. At the same time, you can change in several merge-requests: status, stage (milestone), label (label), description, or developer, to which merge-request is assigned.

Project management with a lot of merge-requests will become much easier!

Build grouping

If you have a lot of similar builds, your pipeline scheme becomes very long. We made a small change to improve its appearance: similar builds will automatically be grouped with each other.

Extended syntax highlighting

With the transition to rouge 2.0.6, we added syntax highlighting for JSX, Prometheus, mxml, 1C (1C, Karl!), Turtle / trig, vhdl, and improved the highlighting for Swift 3.

Sentry integration into Workhorse

GitLab-Workhorse can now send application errors to Sentry.

For details , see the GitLab-Workhorse documentation.

GitLab Runner 1.6

We are also releasing GitLab Runner 1.6 today. Key points:

• Kubernetes executor ( 30 and 277 ), this allows the number of CI runners. It will be processed.
• Autocompletion of / ci in GitLab URL while registering the Runner ( 289 )
• It is executed ( 106 ) for configuration options for specifying scripts.
• Improvements in passing CA certificates to builds ( 299 )
• Improvement in disabling recursive submodules fetching / cloning ( 314 )
• Improve docker machine logging ( 234 )
• Investigation from another container ( 236 )
• Generate a BuildError instead of SystemError when Docker / Kubernetes image is missing ( 295 )

You can view the full list of changes in the Runner changelog .

GitLab Mattermost 3.4

GitLab 8.12 includes the Mattermost 3.4 , an open source alternative to Slack , the latest release of which offers 700 integrations with full Markdown support via Zapier, a simplified bot and OAuth2 authentication, and (added by members of our community) integration with Gitter, Heroku, Pivotal Tracker, Chef, Ansible and Yunohost.

Performance improvements

• Sidekiq processes now use connection pooling when using the Rails caching mechanism: merge request
• Now the gem oj to speed up JSON processing: merge request
• The projects.last_activity_at column is updated only once per hour to reduce the load on the database: merge-request
• The projects.pushes_since_gc column has been moved from the database to Redis to reduce the load on the database: merge request
• Checking protected branches is not performed when the name of the branch is unknown, which reduces the amount of time spent on this process: merge request
• Checking whether someone can close a comment to a commit is done only when comments can be closed at all: merge request
• The ci_runners table ci_runners now updated less frequently to reduce the load on the database: merge-request
• Reduced the number of database queries used for the "Builds" tab for commits / merge-requests: merge-request
• Reduced the maximum size of the calendar of actions:
  Merge-Request

Changes in access rights for assemblies

GitLab 8.12 introduces important changes to permissions for assemblies

We decided that the access rights of the assembly should be closely related to the access rights of the user who launched this assembly. There are the following reasons:

• We already have a permissions system for users (based on which group or project the user belongs to)
• We know which user starts the build (no matter how exactly - using push in Git, via the web or via triggers).
• We know what is allowed to this user.
• For assemblies that were started by pushing, we give the same rights that the user who made the push had (agree, it’s convenient when your assembly has access to everything that you have access to)
• We can create unique short-lived tokens that provide the necessary access for the lifetime of the assembly.
• It is very well correlated with our philosophy "everything must be integrated with each other)
• This approach allows you to do with access rights a lot of interesting things: for example, to give only individual users access to runners, secret variables and deployment environments (environments).

Now any assembly started by the user will have the access rights of this user. When a user makes a git push or modifies files through the user interface, we create a new pipeline. This pipeline will belong to the one who made the push, and builds created in this pipeline will have access rights to the one who made the push.

This will allow us to facilitate the process of accessing all dependent projects and images of containers to which the author of the assembly will have access. Access rights are granted only for the duration of the build; after the assembly is complete, access will be revoked.

For more information about the permissions of assemblies and changes in this regard, see our documentation .

If you are interested in the history and reasons for this change, you can read the full discussion in the relevant article .

Sub-modules in CI

Submodules are one of the reasons why we reworked access rights for assemblies. Now it's much easier to use submodules in your CI builds.

To use submodules, you must have a .gitmodules file that looks something like this:

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

To use new permissions for assemblies for your submodules, you need to convert your URLs into relative ones:

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

This will force Git to use the same login and password as for accessing the project’s sources.

The last step is to tell GitLab CI to deflate the sub-modules:

 before_script: - git submodule update --init --recursive 

You can find out more about the support of submodules in our documentation .

Other changes

There are many other changes in this release, including various security fixes. To view all the changes, refer to the loglog .

Update barometer

This release will require additional time, since foreign keys have been added, column types have been changed, and some columns have been moved between tables. The entire migration process for large instances can take up to 30 minutes. In small instances, the delay is assumed to be about 10-15 minutes.

(EE only) Reindex Elasticsearch

We changed the structure of the Elasticsearch index for repositories using parent-child relationships. You will have to completely rebuild the whole ES index. Elasticsearch 2.3.x also contains a bug that causes failure of all requests that simultaneously use the "highlight" feature and the parent-child connection, and therefore we recommend using version 2.4 or newer. After upgrading to GitLab 8.12, you need to delete the old index and rebuild the new one.

To delete the old index, make the following request to Elasticsearch:

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

Then rebuild the new indexes as described in the Elasticsearch integration documentation.

Ruby Update

In the previous release post, we mentioned that GitLab 8.13 will no longer support Ruby 2.1.x. We changed our mind and will not stop supporting Ruby 2.1.x in the near future.

We still recommend that you upgrade to Ruby 2.3 if you are running the installation from source, as this is the same version that comes with Omnibus.

Advanced Sending of User Data (EE)

To give us more information about the use cases of our product, GitLab 8.12 EE now sends additional data to the server.

We do not collect any user information (such as project names, comments, file contents, etc.). You can view the sent data in the administrator settings, where you can optionally disable this feature entirely.

Detailed information - in the corresponding merzh-request.

GitLab-Workhorse secret key

GitLab-Workhorse now uses the secret key to sign some messages sent to the Rails GitLab application. For now, this is primarily a configuration validation check; In future releases, we want to add features to GitLab-Workhorse that require this private key to confirm trust.

If you use Omnibus, or you installed GitLab from a source with our official init.d script, your secret key will be generated and set automatically. If you are using your init.d script or are using packages not created by GitLab Inc., you will need to set the -secretPath option to GitLab-Workhorse.

Something else

We assume that you are updating from the latest version. If this is not the case, check out the update barometers of intermediate versions that you are missing. If you are upgrading from GitLab version to 8.0 and you have CI enabled, you should first upgrade to GitLab 8.0

Please remember that the original Omnibus packages will stop, start the migrations, and start again regardless of how large or small the update will be. To change this behavior, add the file /etc/gitlab/skip-auto-migrations .

Installation

If you are installing GitLab from scratch, read the appropriate section .

Update

Follow our updates .

Enterprise Edition

GitLab Enterprise Edition includes additional features such as support for LDAP groups. Detailed information can be found in
description of GitLab EE .

GitLab EE is available only by subscription .

Not enough time to install and configure a new tool? The cost of the subscription includes the installation and update services GitLab on your servers.

Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru , nick_volynkin , rishavant and chebureque worked on the translation