GitLab 11.4 released with a review of merge-requests and plugin features

Original author: GitLab
  • Transfer

Picture to attract attention

We are pleased to present a new release of GitLab 11.4 with long-awaited updates designed to help teams work more efficiently. Most teams that use DevOps tend to shorten the delivery cycle time. Therefore, developers are always happy to improve, which will reduce the amount of work and loss in time, because this accelerates the delivery of the product and improves business performance.

With GitLab 11.4, we make the code review more efficient due to the merge requests and the file tree for changes ; We also present an alpha version of the pluggable features (feature flags, feature toggle) . Auto DevOps and CI work better in conjunction with PostgreSQL database migration and scheduled incremental deployment . Even Git is now faster with Git v2 protocol support .

Review Code

The Merge Requests Review will help streamline comments on the code and Merge Requests. Batch comments (batch comments) allows the reviewer to write comments on the code or merge-requester and then issue and send them in one package, and now tracking changes in the project has become easier.

The key step to delivering a high quality code is to choose the right people who review and confirm changes in the code. Taking the owners of the code entered in release 11.3 ( original article , translation ) as a basis, GitLab now offers those who have been indicated in the file CODEOWNERSas reviewers and confirmations for merge requisition. Thus, review and confirmation of changes will be carried out faster and more efficiently. This is also useful for separating roles and responsibilities in a team, for example, if you need specific reviders for specific parts of the code.

The presentation of the Merge-Requester changes in the form of a file tree also makes it easier for reviewers to view the many changed files and provide their feedback.

Russell Levy, one of the founders and technical director of , told how the review of merge-requests and the tree view of files help their team:

We conduct the code review very carefully and usually write 10-20 comments on the average merge requester, and for some of them several iterations of discussions arise. The Merge Requests Review reduces chaos and hitch during the review code process.

For large merge-requests, the new representation of changes in the form of the file tree greatly facilitates and speeds up the review, allowing you to easily navigate through the code to understand the dependencies.

Plug-in features

We present the alpha version of the functionality switching system - plugin features . Now teams can practice continuous delivery, adding new features to the production in small batches, reducing the risk before full deployment.

Improvements for Auto DevOps and CI / CD

We derive the possibility of подключения дополнительных файлов в файл .gitlab-ci.ymlusinginclude of Starter Plan Core Plan, making it accessible to all users. All teams can now take advantage of this best practice and more efficiently manage their CI / CD pipelines.

And more improvements.

Together with the huge GitLab community in this release, we added a lot of amazing improvements, including a new profile page view, quick access to status, highlighting mentions @имени, new quick actions, and the ability to close epics.

Read on and you’ll learn about all the new features of GitLab 11.4.

We invite you to our meetings and webcast release 11.4 .

GitLab MVP badge

This month's MVP is Luke Picciau

Luke added the ability to download a file with recovery codes for two-factor authentication , which will simplify their backup. These codes will be required to log in to your GitLab account if you lose access to your phone or one-time secret secret.

Thank you, Luke, for this contribution!

The main features of the release of GitLab 11.4

Review of Merge Requests


Merge Requests Review is a powerful feature of GitLab. Team members lead discussions tied to specific lines of code in the differential, and can even solve them. However, this process can become difficult in merge-requests with large diffs. Often the reviewer has to leave 10 or more comments in one discussion, and the 9th or 10th comment may make previous comments unnecessary. As a result, the author of a merge-request receives a lot of notifications, and he has to deal with everyone.

In this release, we present the Merge Requests Review. This will allow the reviewer to write as many comments to the draft as he needs, make sure that they are all necessary, and then send them in one action. Since the drafts are saved in GitLab, the reviewer can divide his work into several sessions, for example, start a review on his desktop at work and finish it in the evening at home on the tablet. When these draft comments are sent, they are displayed as normal individual comments. This will give individual team members the opportunity to review the code as it is convenient for them, but still with the entire team.

In future releases, we will improve this feature and provide an opportunity to see a preview before sending a comment package, and also group the notifications of these comments into one notification .

Merge Request Reviews

Discussion documentation and original ticket .

Creating and using pluggable features in your applications (alpha version)


This feature allows you to create plug-in features for your software and manage them directly in the product. Simply create a new plugin feature, confirm it in your software using simple API instructions, and you will be able to control the behavior of your product in the field using the plugin feature in GitLab itself.

Plug-in features offer a functionality switching system for your application. It will allow teams to achieve continuous delivery (CD), sending new features in production in small batches for controlled testing, sharing sending features with launch for customers.

At the moment, this system is presented in alpha version. We suggest that you check how it works and leave feedback, but do not forget that the implementation may change in future releases.

Create and toggle feature flags for your applications (alpha)

Documentation on plug-ins and original ticket .

File tree for viewing merge-request changes


Code review is a necessary practice for any successful project, but from the list of changes it can be difficult to understand what has changed. To facilitate this task, GitLab now provides a tree of files for changes that you can search by.

The file tree displays the structure and size of changes, as it already works with diff-stats, providing a general outline of changes and improving navigation between diffs. A search through the tree gives the viewers the opportunity to limit themselves to part of the files along the path or file type, simplifying the review by specialists who want to focus only on the part of the merge request.

Previously, the list of modified files was available through a drop-down list with a search that was best suited to go to a specific file.

File tree for browsing merge request diff

Documentation for merge-requests and navigation in diffs and the original ticket .

Code owners are offered as confirmation merzh-request


It is not always obvious who will be the best candidate to review your changes. Code owners are now offered as confirmation when creating or editing a merge request to simplify the assignment of the right people to this role.

Support code owners appeared in the release of GitLab 11.3 ( original article , translation ). In future releases, the degree of participation of code owners in the work process of merge-requests with automatic assignment as confirming and required confirmation of the owner will increase .

Suggest Code Owners as merge request approvers

Documentation on the confirmation of merge-requests and the original ticket .

Updated profile page view


No matter what role you use GitLab, your activity is a significant source of information and an indicator of your engagement displayed on your profile page. Your profile should easily give an idea of ​​what you are interested in and what you are working on.

In this release, we updated the user profile page, reducing the schedule of development contributions already familiar to you: it now displays your recent activities and the most important personal projects in GitLab.

New user profile page overview

Documentation on the user profile and the original ticket .

Display and change of status in the user menu


In the release of GitLab 11.2 (the original article , translation ), we first presented the status of users, providing the opportunity to share your current workload, mood, or at least your favorite animals.

In this release, we simplify the status change. The new item “Set status” in the user menu will allow you to set or clear the status without leaving the context. It also displays your current status with a message and Emodzhi - at the top, along with your name and nickname.

Set up your user menu.

Documentation on statuses and original ticket .

Connecting additional files in .gitlab-ci.ymlvia is includenow available in Core plan


We are happy to announce that starting with this release use includein .gitlab-ci.ymlmoved from the Starter Plan Core Plan. Thus, templates and other shared resources will always be available for free and paid users, and everyone will have the opportunity to use this advanced development technology with reusable snippets for CI / CD pipelines.

Ability to use includes in `.gitlab-ci.yml` from Starter to Core

Documentation on include and original ticket .

Run jobs only/ exceptfor changes in the file path or in the file


We are pleased to present what you often asked for - the ability to use the rules only/ exceptin .gitlab-ci.ymlfor work if changes occur in a particular file or along a specified path.

This will give more control over repositories containing various resources and assemblies, since now only the necessary steps will be performed for new changes, which will speed up the work of the pipeline as a whole.

Run jobs `only` /` except` for modifications on a path or file

Documentation on the use of restrictions in the changes and the original ticket .

Added incremental scheduled deployment in Auto DevOps


The ability to run an incremental deployment in Auto DevOps has been available for some time, and with this release we add the ability to launch a deployment on a schedule , so that it will automatically run on a specified schedule, if no errors occur.

Add timed incremental rollouts to Auto DevOps

Scheduled incremental deployment document and original ticket .

Kubernetes RBAC Support for GitLab Applications


When setting up your infrastructure for the first time or connecting to an existing primary factor, security is a must. Role-based access control (RBAC) has become publicly available (GA) in Kubernetes 1.8 release, providing more precise control over access control to Kubernetes resources.

Our integration with Kubernetes now offers the ability to either create a cluster in GKE (Google Kubernetes Engine) with RBAC connected, or connect to an existing RBAC cluster, which will make your infrastructure safer.

Support Kubernetes RBAC for GitLab managed apps

Documentation on clusters with RBAC and original ticket .

RBAC support in Auto DevOps


Auto DevOps now also supports application deployment on Kubernetes clusters with RBAC connected.

Role-based access control is an important tool that helps operators (deployment managers) ensure the reliability, security and efficiency of Kubernetes clusters. Using Auto DevOps in conjunction with a cluster with RBAC connected ensures that your applications get all the benefits of increased infrastructure security.

Auto DevOps support for RBAC

Auto DevOps documentation and original ticket .

PostgreSQL database migration support and initialization for Auto DevOps


We have improved the capabilities of Auto DevOps to automatically detect, build, test, deploy, and monitor your applications. Starting with release 11.4, Auto DevOps provides the ability to initialize or migrate PostgreSQL databases into your project.

Simply set a project variable to initialize or migrate your PostgreSQL database, and Auto DevOps does the rest.

Support PostgreSQL DB migration and initialization for Auto DevOps

Documentation for automatic deployment and original ticket .

Other improvements in GitLab 11.4

List of tags you follow


Labels in GitLab are very versatile, as they can be applied to tasks, merge requests and epics. But the more tags you use, the harder it is to keep them in order.

In previous releases, we added a search for tags on the page with a list of project tags. Starting with this release, you can search for tags, sort them by name, creation date and change date, and view a list of tags that you are subscribed to. All this is available in the lists of group tags and tags associated with the project.

List of subscribed labels

Search documentation for tags and original ticket .

WIP Merge Requests Filtering


Merge Requests are one of the main parts of GitLab. They allow project participants to work together on code, while respecting transparency. We are for the teams at the early stages to share their work and use the WIP feature (“work in progress”, “in the process of development”), which shows that active work is still underway on the merge request, and it is still too early to be inhibited.

In this release, we added a new filter for Merge Requests, which works both at the group level and at the project level, which helps users to more easily distinguish between WIP and non-WIP requests (“in work” and “ready”). This allows users to focus on merge requests, which are still in the early stages of work, unlike those that are closer to the final stages of testing before merge.

Filter by WIP merge requests

WIP filter documentation and original ticket .

Selection of personal references


In discussing a task or a merge-request with a large number of participants, it is difficult to see which comments are addressed to you.

Starting with this release, all references to the @имениcurrent user will be highlighted in a different color, which allows you to immediately see which comments are sent to you, and quickly focus on them.

Highlight `@ mentions` for yourself distinctly

Documentation of references and original ticket .

Inserting GFM-tables and links in Markdown on click


GitLab supports GitLab Flavored Markdown (GFM) in most text input fields, expanding the formatting capabilities with a simple syntax. In particular, you can create tables on GFM. Previously, this function was difficult to use, especially when working with large tables, since you had to enter a lot of characters or insert the previous table in order to format it as you like. GFM also supports link management. But sometimes it is difficult to remember which syntax to use in this case.

Starting with this release, you can simply click on the button with the image of the table in the GFM editor, and the table will be inserted automatically. Then you can easily fill in the cell values ​​of the table or extend it, customizing as you like. This feature can be used in descriptions and comments throughout GitLab.

Similarly, by clicking on the insert link button, you will get a template for the URL into which you can quickly insert the link address and its name.

Thanks to George Tsiolis for developing table inserts!

Thanks to Jan Beckmann for developing URL insertion!

Click to insert Markdown table and link

GFM documentation and original ticket .

Inclusion of new tasks in the work schedule


Burndown charts help teams keep track of progress in performing their work on malystone. Usually the amount of work is discussed and approved before milestone begins. But sometimes this rule has important exceptions (such as an unexpected bug or a solution to a security problem), and you have to create new tickets for emerging tasks.

Starting from this release, work schedules will show information about new tasks that are created in the middle of Milestone, which is why a jump occurs on the graph.

Include new issues created in Burndown Chart

Extended range of weights in the task API


Starting from the previous release, the values ​​of task weights can vary from zero to infinity (within reasonable limits).

In this release, we added the ability to set weights with a wider range using the task API.

Task API documentation and original ticket

Quick discussion blocking


Locking discussion of tasks and merge-requests helps to shift attention from old tasks and merge-requests to more urgent ones. You can also use this feature to prevent aggressive or unproductive behavior.

In this release, we added quick actions to lock and unlock discussions, so now you can lock / unlock discussions along with posting a comment.

Thanks to Mehdi Lahmam for this feature!

Lock discussion quick action

Quick-action documentation and original ticket .

Closing epic


This release adds the ability to close (and reopen) epics in GitLab, as well as tasks and merge requests. In the list of epics, there are now the Open (open), Closed (solved) and All (All) tabs, similar to how it is implemented for tasks. So now, if you have completed all the work on the epic, or it is no longer relevant, it can be marked as completed (closed), and it will no longer appear in the list by default.

Now you can close and reopen the epic using the appropriate buttons or through quick actions, as well as through the API, as a task.

Close epics

Documentation on the epic and original ticket .

Improved admin settings panel


Because of the large number of features that GitLab provides, administering GitLab can be quite a challenge.

In this release, we have made the admin settings panel more convenient to use. Now all sub-sections of individual settings are on separate pages, which gives the administrator quick access to any settings that he needs to change.

Improve Admin Area settings structure

Documentation on the admin settings panel and the original ticket .

Sort projects by popularity


Our development team is doing everything possible to make it easier for you to search for relevant and interesting projects in your GitLab instance. In this release, a new filter “Most stars” (sorting by the number of likes) has been added, which allows you to find projects with the highest number of marks in your instance.

Thanks to Jacopo Beschi for this feature!

Explore projects by popularity

Documentation on the search for projects and the original ticket .

Displays the percentage of programming languages ​​used on the project page


Recently, we added language usage statistics to the project review page, which gives a general idea of ​​which programming languages ​​were used in development.

In the version of GitLab 11.4, we added a display of the percentage of the code in each language. This allows you to get a quantitative description of the technology stack of your project.

Thanks to Johann Hubert Sonntagbauer for this feature!

Display code language percentage on project overview

Documentation for programming languages ​​in the repository and the original ticket .

Downloading two-factor recovery codes


Actual two-factor authentication is standard when logging on to any modern web application. We, the developers of GitLab, understand this and take your security seriously. Every time you set up two-factor authentication, we provide a limited set of access recovery codes that allow you to regain access to your account in case of emergency.

Starting from this release, it is possible to download recovery codes as a text file using the “Download codes” button.

Thanks to Luke Picciau for this feature!

Download two-factor recovery codes

Documentation on recovery codes and original ticket .

Filtering by type and status in the Runners viewer


The Runners viewer now supports the ability to filter them by type and state, which gives you more control over large sets of runners in the project environment.

Filter admin Runners view by Runner type and state

Runners documentation and original ticket .

Support for interactive web terminals added to Docker


We expanded the functionality of interactive web terminals and made them compatible with Docker implementers. Currently, the Docker session ends as soon as the corresponding script ends, but we are working on this problem , and we hope to solve it for the next release.

Support for interactive web terminal to docker executor

Documentation for interactive web terminals and original ticket .

Skipping Auto DevOps jobs when features are unavailable


Starting with version 11.4, Auto DevOps will evaluate the plan (when hosting on or the profile (when self-hosting) for the instance in which it is running to determine which work should be skipped. As a result, the Auto DevOps pipeline will run faster as unused features will be skipped.

This will save you time, and now your pipeline schedule will look neater, as it will only be marked relevant to your project.

Auto DevOps documentation and original ticket .

Conveyors can set the execution of works on a schedule.


The new release has the opportunity to postpone the start of work through the 'when' keyword in the file gitlab-ci.yml. Time counting starts from the moment when the work should start to be performed taking into account the delay, which gives you the opportunity to add work that should be performed after a certain period of time - for example, using incremental deployment or in other cases where further actions should be performed after the delay.

Allow pipelines to schedule delayed jobs

Job posting documentation and original ticket .

Interactive task lists with Nurtch and JupyterHub


Interactive task lists (runbooks) give operators an excellent opportunity to interact with various systems to perform diagnostics, deployment and evaluation of infrastructure components.

JupyterHub, an application accessible through the integration of GitLab and Kubernetes, now includes the Nurtch Rubix library , which makes it possible to create task lists for DevOps. As an example, a test list of tasks is presented, demonstrating the basic operations .

Interactive runbooks with Nurtch and JupyterHub

Documentation for installing applications and the original ticket .

Added manual entry when filling in lists of licenses


The license management policy allows developers to confirm the use of individual licenses in a project, or to blacklist them. This can be done directly on the merge-request page, as soon as a new license appears. But sometimes Maintainers want to make a list of licenses in advance so that developers know if the changes they make are consistent with the project's policy.

In GitLab 11.4, we added the ability to manually enter when compiling a list of licenses. Maintainers can fill in the list on the Settings> CI / CD> License Management page , choosing licenses from the standard set or adding them manually.

Add manual entries for License Management

Documentation for manually filling in the license lists and the original ticket .

The metrics panel now displays alert thresholds.


Starting with GitLab 11.4, the specified alert thresholds are displayed directly on the metric graphs. This makes it easier to determine which metrics generate alerts at the moment, and also allows you to get a visual idea of ​​the interaction between metrics and alert thresholds.

Alert thresholds now displayed on metrics dashboard

Alert threshold documentation and original ticket .

Git v2 protocol


Developers update local repositories ( git fetch) several times a day to check if the current branch is lagging behind the latest version of the branch in the repository. The Git v2 protocol is an important update of the data transfer protocol , which is responsible for the exchange of data between the client (your computer) and the server (GitLab) during cloning, extraction and pushing. The new data transfer protocol improves the performance of fetches and makes it possible to further improve the protocol.

Previously, when invoking fetch commands, a list of all links in the repository was displayed. For example, if you update for one branch ( git fetch origin master), then you will also see a complete list of all links. When it comes to a big project, you can get more than 100,000 links and dozens of megabytes of data.

Git v2 protocol has been supported since Git v2.18.0, but is not used by default. To activate it, call the command git config --global protocol.version 2. On, the Git v2 protocol is not yet connected by default when working over SSH. If you want to use it, you need to connect it manually.

Documentation for setting up the Git v2 protocol and the original ticket .

Improved UX Geo admin settings panel


For a Geo administrator, it is critical to monitor the loading and synchronization of secondary nodes when working with geographically distributed commands.
In GitLab 11.4, we improved UX Geo on the admin panel, adding even more synchronization and verification information to the user interface. When you click the “Open projects” button in the profile on the primary node, a link to the list of projects on the corresponding secondary node is generated. The profiles on secondary nodes in the new “All” tab contain basic information on the verification status of all projects.

We have plans to further improve the UX !

Geo UX

UX Geo documentation and original ticket .

Prometheus 2.0 Update for Omnibus GitLab


Omnibus Gitlab comes with Prometheus, which provides a visual representation of deployed instances . The Prometheus development team has released a major update in the form of a new 2.x series, which includes a number of improvements , including improved performance and a more convenient time series database format. Unfortunately, the change in the database architecture has led to the fact that it does not support backward compatibility with the old format of the 1.x series.

Starting with GitLab 11.4, Prometheus 2.4.2 is included in the Omnibus package, so you can already take advantage of it.

For more information on updating Prometheus to 2.4.2, please refer to our update documentation .

Documentation for updates and original ticket .

Detailed release notes and upgrade / installation instructions can be found in the original English post: GitLab 11.4 released with Merge Request Reviews and Feature Flags .

Cattidourden , rishavant and @maryartkey worked on translation from English .

Also popular now: