GitLab 8.10 released

Hello. This time, the delay in the release of the release post turned out just 10 days, and it pleases.
This time he translated chebureque , for which he was very grateful!

In short: Increased productivity, appeared protecting branches from changes using masks, improved diff display, added manual actions to CI, mass subscription to tickets, improved support for Slack, and added more emoji.

The text of the translation itself:

The main task of GitLab is to allow you to go from an idea to a ready-to-use product as quickly as possible. Each of our releases is aimed at making this path even easier, and version 8.10 especially succeeded in this!

GitLab 8.10 simplifies review and merge code processes: now you have even more convenient diffs and additional features to protect branches from accidental changes. And when it comes time to deploy the finished code, you can use the function of manual checks before you deploy your code with one click.

Our July ( MVP ) - Winnie! He helped us a lot by correcting bugs and putting order in our issue tracker .

Protection of branches against changes using masks

To protect the branches from accidental deletion or modification, they can be protected. This mechanism, among other things, allows you to allow or deny access to the branches for writing, depending on the rights of users - for example, you can prevent ordinary developers from pushing or merging into production and release branches.

In Gitlab 8.10, you can now set up such automatic protection using masks that will be applied to branch names. This greatly simplifies working in repositories with a large number of branches.

For example, if you put a protection on a release-* mask, all branches whose name begins with release- will automatically become protected. When developing GitLab, we use this feature to protect our stable branches using the *-stable mask.

Merzh in the protected branches

As mentioned above, the branch protection option allows you to distinguish between who can push into important branches and who cannot. By default, push and merge to protected branches is available only to users with Master permissions and above.

In previous versions of GitLab, users of the 'Developer' group were automatically allowed to push into secure branches. Starting from version 8.10, you can independently give Developer members rights to push separately and separately to Merge.

In this example, members of the Developer group may have merge requisitions, but cannot directly push into the specified branches. That is, these branches are protected from direct pushing, but for accepting a merge-request, they do not need to wait for a user with a high level of permissions. Please note that this functionality is available only from the web interface and is not available from the command line.

Here you can also add approvals from the Enterprise Edition, which allows you to require a review from several people before accepting changes. In this case, a merge-request must be viewed by several developers, but any user from the Developer group can nevertheless accept it.

Read more about secure branches.

Improved Dify

Regardless of whether you are writing code, doing code review, or even working not with code, but with some other text content, you most likely have to work a lot with diffs. It is very desirable that the diffs work quickly and be comfortable. In GitLab 8.10, diffs began to be rendered much faster and learned a few interesting things.

More comfortable side-by-side diffs

We have improved the side-by-side diffs, and now they show the changes in an even more visual form.

Inline diffs

If the changes affect only part of the line, we will show you exactly its modified portion (and not the entire string):

Shattered Diffs

Now you can slap diffs by clicking on the file name. This will help you conveniently view the changes file by file.

Large diffs ( > 10kb ) will always be shown collapsed (but you can deploy them at any time). This should be a great help if you constantly have to look through a lot of big changes in a lot of files.

Manual actions to run pipeline tasks

Of course, you have already set up a pipeline (pipeline) for Continuous Integration / Continuous Delivery ? Using such an automatic pipeline for production deployment may not be the best idea. Automatic deployment to staging is quite a normal practice, but before porting the code to production, it is better to do at least a few manual tests to finally make sure that everything is working fine.

Now you can set manually activated conditions for deployment in production. The when: manual option adds a new action to the web interface that needs to be activated manually — and the pipeline will continue to be executed only after this manual action. For example, your release manager will click this button after manually making sure that staging is working fine. Any job in your pipeline can be marked with the when: manual option.

These actions are also displayed in environments to make it easier for you to translate assemblies from staging to production.

About the CI / CD system in GitLab
Environments in CI

Multiline syntax for quotes in markdown

If you want to mark several lines in your markdown file as a quote, you no longer need to add to each line > . Now for this there is a multi-line syntax:

 >>>       .      . , ! >>> 

Read more about GitLab Flavored Markdown

Multiple mount points for repositories

Now you can spread the data of your repositories across several mount points. Just enter all the necessary mount points in the gitlab.rb file:

 git_data_dirs({ "default" => "/var/opt/gitlab/git-data", "alternative" => "/mnt/nas/git-data" }) 

After that, in the GitLab admin panel, you can specify under which mount point each new repository should be stored.

Learn more about multiple mount points.

Bulk subscription to tickets

Now you can subscribe (and unsubscribe) to a large number of tickets at the same time. This is useful in cases where you want to dive straight into a new project and be aware of everything at once, or vice versa, want to be in silence from constant email notifications.

Individual alert levels for groups

In the previous version (8.9), we added individual alerts so that you would receive notifications only about project events of interest to you.

In GitLab 8.10, you can manage these settings for project groups by setting the same alert settings for several projects at once (do not forget that individual project settings take precedence over group settings).

Ticket-based Kerberos authentication (only available for Enterprise Edition)

Prior to version 8.10, GitLab users who wanted to use Kerberos authentication had to enter the login and password of their Kerberos account on the GitLab login page. Since version 8.10, GitLab Enterprise Edition allows Kerberos users to log in to GitLab without entering a username and password - now you just need to click on the "Kerberos Spnego" button on the login page.

This is made possible by the new OmniAuth provider for SPNEGO authentication via Kerberos. This provider uses the CERN Institute for Nuclear Research , with which it became possible for GitLab to do git clone using ticket-based authentication via Kerberos.

If the user's browser "understands" the Kerberos protocol, and the user himself has a valid Kerberos ticket on his machine, the browser will automatically log in to GitLab without asking anything from the user.

Detailed information on configuring ticket-based authentication via Kerberos for GitLab Enterprise Edition is available in the corresponding documentation section .

In the next release, we will remove password-based authentication through Kerberos, so if you use it, we recommend that you switch to the ticket-based option as soon as possible.

Syntax highlighting

The syntax highlighting in GitLab 8.10 is even better.

We updated rouge from version 1.11.1 to 2.0.5, and in the process of this update added new lexers and fixed several bugs . Now we have the backlight for Docker, F #, IDL, and the already available backlight for praat,
JavaScript, Java, C #, Shell, Liquid, Tulip, Markdown, Ruby, Python and YAML have become even more beautiful!

By the way, now you can redefine the “guessing” of the language for highlighting and set it explicitly using the entry in the .gitattributes file.

All details are in the relevant documentation .

Deny access request

Now you can prohibit users who are not members of a project or group from applying for membership there . By default, such requests are allowed.

Improved Slack Integration

GitLab can now notify you about various project events via Slack - whether it be a comment to a ticket, the creation of a new merge request or a broken build.

Slack service now allows you to configure which Slack channel will receive a message about each event.

Read more about Slack Service here

New Emoji!

We have upgraded to gemojione for 2016, and now emoji has become even more.

Blacklists for domain names

Now you can blacklist domain names, and email addresses from these domains will not be able to register with your GitLab instance. The settings associated with the blacklist are in the admin panel.

Read about it here.

Enable and disable access protocols for Git

Now you can independently manage access protocols to Git: you can only allow access to the repository via HTTP, only via SSH or simultaneously via HTTP + SSH

Read more

Display video in text

If the text of the ticket, commentary or merge-request contains a link to the video, then GitLab will display this video directly in the text.

Read more about GitLab flavored markdown

Warnings during assembly

As you know, the CI pipeline can be configured in such a way that errors when performing certain tasks (jobs) in it are not considered fatal . When such errors occur, the CI pipeline displays warnings (warnings). In GitLab 8.10, these warnings will be visible to you on the merge request that caused them

Usage statistics (for GitLab Enterprise edition only)

To better understand how customers use GitLab, 8.10 EE regularly sends anonymous statistical information to GitLab, Inc. servers. If you don’t like the idea, turn off this option on the "Application settings" page (on the same page you can see what data will be sent to our server.

Performance improvement

From release to release, GitLab is getting better and better in all respects - including speed. This month we accelerated the display of tickets by 2-2.5 times and diffs by a third:

For those interested - here is a list of significant changes in version 8.10 and links to the corresponding requests.

Backend

• HAML has been replaced
• Certain Git operations are now cached pipelines when finding CI pipelines
• Multiple operations
• Files
• If you’re quoting SQL queries
• projects column.pushes_since_gc
• If you’re an avatar is present
• Checking if you have a single project has been optimized.
• These queries are now cached per request.
• Wiki is now online
• Performance of Markdown has been improved.
• Checking whether to have a system note has been optimized
• If you’re commenting, you’ve been cached to prevent multiple lookups.

Frontend

• Rendering of UI elements when necessary
• It is also possible to reduce the amount of load per page.
• Cropper.js has been separated from the main JavaScript file.
• Hen’t want to get
• Discussion notes are not rendered when it is requested using Ajax
• The code used to check

Monitoring

• Sidekiq latency is now tracked
• Redis cache hits and misses are now tracked
• The Markdown syntax highlighting filter is instrumented

Runner v1.4

From now on, runner releases will be synchronized with the monthly major GitLab releases. Changes in this runner release ::

• Use Sentry in GitLab Runner to monitor critical errors
• Improve logging
• Extend support for caching and artifacts for other executors
• Add support for cloning VirtualBox VM snapshots
• Improve support for Docker Machine
• Improve build abort

GitLab Mattermost 3.2

Together with GitLab 8.10 comes Gitlab Mattermost 3.2 , an open version of Slack.

German localization, new emoji, improved thread display, full-screen search interface, integration with MS Exchange and XMPP, and much more were added to Mattermost 3.2.

In addition, several security updates have been included in this version of Mattermost, so we strongly recommend upgrading to it.

Other changes

This release includes many other improvements, including various security fixes. A full list of changes is available in Changelog .

Upgrade barometer

Upgrading to GitLab 8.10 will require 15-30 minutes of downtime. During the update, several columns in the database will be renamed, and several migrations will be performed to correctly update the data. In order not to damage your data during the migration process, the GitLab instance will be stopped for the duration of the update.

Nginx configuration update

The default Nginx configuration for GitLab now overwrites the HTTP headers 'Host' and 'X-Forwarded-Host'. This adds an extra layer of protection against header injection attacks. If you installed GitLab from source, then you will need to update your Nginx configuration. If you installed GitLab using Omnibus, the configuration will be updated automatically (unless you override the 'Host' and 'X-Forwarded-Host' gitlab.rb in the gitlab.rb file).

Git Hooks renamed Push Rules, and obsolescence of Git Hooks API

What used to be called Git Hooks is now called Push Rules. In addition, the Git Hooks API is now marked deprecated. This API will be completely thrown into GitLab 9.0, so we recommend that you switch to Push Rules as soon as possible.

Learn more about Push Rules

Default behavior when updating

Warning The information in this section is relevant if you are upgrading to GitLab 8.2 from a previous version. If this is not the case, then read the “Upgrade-barometer” sections for all intermediate versions between your current and 8.2.

If you are upgrading from a version of GitLab smaller than 8.0 and at the same time you have CI enabled, you must first upgrade to 8.0 .

By default, during the update process, all Omnibus packages will be stopped, then all their migrations will be rolled out, and only then they will be started again. This behavior does not depend on the size of the update. You can change this behavior by creating the /etc/gitlab/skip-auto-migrations file.

Installation

If you are installing GitLab from scratch, read the relevant section: https://about.gitlab.com/installation/

Update

Update instructions: https://about.gitlab.com/update/

Enterprise Edition

GitLab Enterprise Edition includes additional features such as support for LDAP groups, confirmation of merge requests, file locking, and more. Detailed information can be found in the description of GitLab EE .

GitLab EE is available only by subscription, details and prices can be found here .

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.

PS If we missed, here is a link to the translation of a post about release 8.9