GitLab 8.11: Kanban board and conflict resolution with one click

This article is a translation of a GitLab release article. The releases are released every month on the 22nd.

If you missed the previous ones, here are the links: 8.10 , 8.9 , 8.8

In the new GitLab 8.11 there are so many interesting things that we can hardly restrain ourselves in the framework of a constructive story!

So, in the new version appeared:

• a fundamentally new way of presenting and working with issues (issues);
• slash commands ( /command ) for working with tickets;
• the ability to create ticket templates (in unlimited quantities);
• online development environment;
• the ability to resolve conflicts of merge without leaving GitLab;
• setting rights to push to a branch for individual participants and groups (only in EE);
• ... and many other features, which we will also tell about.
  

This month's MVP is Clement Ho. Thanks to him for merge requests and responsiveness in working on tasks.

Ticket Board (Issue Board)

Ticket (issues) in GitLab is a very flexible tool. They may contain links to each other, you can indicate their priorities, you can sort by popularity. The ticket board adds a new way of working with them.

Now you can customize workflows and quickly receive information about the status of tickets. All this is available on a simple and nice looking board, similar to those used in Kanban or Skrama.

A board is created for each project automatically. By default, all open tickets form a backlog, and all closed ones appear in the Done list.

By adding new lists, you create new workflows. The belonging of the ticket to the list is determined by the label. When a ticket is added to the list, the corresponding label is added to it, and if it is deleted from the list, the label is deleted.

If you used to have labels like , and - it's time to make lists of them. Tickets will appear in them automatically. And, of course, a ticket may belong to more than one list.

If you want to look at this feature in action, take a look at the GitLab CE version 8.12 board .

Ticket Board Documentation

Conflict resolution with merzh

Merzy in large and actively developing projects usually cause many problems. We want you to have a built-in conflict resolution tool. Therefore, you can now do this directly in the GitLab interface.

When the merge is blocked by a conflict, you can simply click the "Resolve these conflicts" button and go to the resolution interface. There you can select the desired lines and commit the result.

Of course, not all conflicts can be resolved this way. But we hope that in most cases this tool will help you speed up the passage of requests.

Conflict Resolution Documentation

Permissions to work with branches for specific users (only EE)

Now in Enterprise Edition, you can configure permissions to push or merge to a branch not only for user groups (like developers or owners ), but also for specific users.

New settings can be combined with other functionality, including permissions for subgroups. For example, you can allow only Temlides Pete and Masha to push directly into the branch, but confirm merge-requests to this branch - to all members of the developer level and above.

For each action (push and merg) you can configure any number of authorized users.

Branch Permissions Documentation

"Closing" comments in merge-requests.

In merge-requests there are long branches of comments, in which you can get confused. But each of them is important.

We added the ability to mark a comment or a whole thread as processed and close it.

Merge-Requests now also have a counter for unclosed discussions and a convenient button for moving to the next open discussion.

Documentation for closing discussions in Merge Requests

Schemes of conveyors.

Conveyors in GitLab can have a rather complex structure with many sequential and parallel assemblies. Now you can look at the scheme of a specific conveyor, showing its structure and state. Such a scheme clearly shows the processes occurring in it.

Just click on the pipeline on the merge-request page or in the list of conveyors. You will see a diagram of this pipeline with a display of completed, failed, active, and pending assemblies.

Templates tickets and merzh-requests.

The ability to standardize tickets and merge requests using templates was already in GitLab Enterprise Edition. Starting from GitLab 8.11, there may be many templates - for example, one for errors and another for sentences. And the opportunity itself is in all versions: GitLab.com, GitLab CE / EE.

Templates are written in the Markdown markup and are located in your repository, respectively, in the folders .gitlab/issue_templates and .gitlab/merge_request_templates :

The purpose of this feature is to improve the appearance and completeness of sentences, error messages and merge requests.

Template Documentation

Slash commands

Now GitLab has a slash command ( /command ) - just like in IRC, HipChat, Mattermost or Slack. They allow you to change labels, assign artists, subscribe and unsubscribe from tickets and do much more - quickly and without taking your hands off the keyboard. Commands work in the description of the ticket or merge-request, as well as in the comments.

How to use them:

1. You enter the text containing the command (from the keyboard, from the template, through the API, as you like).
2. Confirm sending a comment, save the ticket or request.
3. Commands are executed and are no longer shown in the text. If the comment consisted only of commands, it will be executed, but not published.

You can use slash commands even when creating a new ticket or request:

If several commands are sequentially specified, all of them will be executed.

A few ideas on how to use slash commands:

• In a letter in response to an alert from a ticket or a merge-request (the text of the letter becomes a comment).
• In the ticket or merge-request template.
• Through notes API .

We ourselves look forward to your stories about what other uses you will invent.

Slash Commands Documentation

Integration with Koding

Koding allows you to run your development environment in the cloud, use the same settings for this environment for the entire team, and even use a local editor. Thanks to this, it is not necessary to spend time on installing and setting up a stack for each new computer and with any change.

Starting from version 8.11, GitLab supports integration with Koding. Now, at the touch of a button, you can download the entire project or a separate merge-request and open it in a full-fledged cloud-based IDE. (note that the integration with Koding has not yet been added to GitLab.com).

Enable Koding support in Admin> Application settings

Set up Koding to work with your project:

And that's it! Now you can quickly dump any merge-request, branch and commit of the project into a full-fledged IDE.

We have prepared a short video showing how Koding + GitLab works:

To learn more about Koding in GitLab, refer to our documentation .

Merchant Requests

Now the pipelines are displayed in Merge-Requests:

Click on the pipeline to see its layout and builds related to it.

Deployment Status Display for Merge Requests

Now you can specify URLs for your environments:

Due to this, GitLab shows the deployment status for merge-requests in cases where the deployment occurs automatically during the merge:

After a successful merge, GitLab will show you a link to the deployment environment, which allows you to see the result of a merge request in one click.

Web hooks for pipelines (pipelines)

To simplify integration with GitLab pipelines, we added web hooks for them. They are triggered when creating, starting, or shutting down a pipeline.

To add a web hook, select Webhooks in the Settings menu of your project.

Highlighting and hiding code

Now GitLab editor supports highlighting and allows you to hide blocks of code.

Links to Merge Requests with Push

Now, when pushing to GitLab, there are links to the creation of a merge-request, as well as to all merge-requests related to the current one.

Test coverage icon

Now you can create icons showing test coverage for your project:

If you did not use the coverage mapping in GitLab, enable it in the pipeline settings: pipelines/settings .

Test Coverage Icon Documentation

Temporary restrictions on access to the project

When issuing access to the project to a single user or group, you can now set a specific date, after which access to the project will be closed for them.

This makes it easier to work with access rights for temporary team members.

Moving projects between shards (only EE)

Multiple mount points were added to GitLab 8.10.

In GitLab 8.11, it became possible to move projects between shards with the help of the rake command. This functionality is not intended for frequent use, however, it may be useful in cases when you want to test a new shard or move a frequently used project to a fast access repository.

Performance improvements

In this release, a number of changes aimed at improving performance were introduced - merge-requests and their diffs became even faster! Below are graphs showing the performance difference after deploying GitLab 8.11 RC2 on GitLab.com (a drop in performance falls on the deployment).

Diff load for merge-requests:

Number of executed SQL queries when displaying diffs:

Time spent on executing SQL queries when rendering diffs:

Also significantly increased the performance of conveyors:

Below is a detailed list of the improvements made and the corresponding Merge Requests:

Improvements

• Improved the process of checking the ability of the user to view several tickets:! 5370
• Improved the process of checking the maximum user access level :! 5412
• Reduced the number of SQL queries to display CI graphs :! 5502
• Added improvements to GitLab with Git, aimed at reducing the number of commands used and faster sorting of version numbers:! 5536,! 5375
• Information about the authors of commits is now cached for each Sidekiq transaction in order to avoid additional selections:! 5537
• Reduced the number of requests used to display a Merge Requests diff !! 5551
• Improved iteration of diff sets:! 5564
• Improved performance of methods that depend solely on diff statistics:! 5568
• Improved the performance of creating diffs by removing unnecessary checks for text blobs:! 5575
• Removed unnecessary calls to methods when creating diffs:! 5591
• Improved diff note check :! 5597
• Improved the process of creating links to ticket tracker:! 5608
• Improved the performance of parsing links in Markdown documents:! 5629
• Improved performance of syntax highlighting of code blocks in Markdown documents:! 5643
• Improved cache key generation process for Markdown documents:! 5715
• Improved the process of sorting Git tags:! 5723
• Trigram indices for ci_runners table ci_runners (PostgreSQL only) ci_runners 5755
• Removed DiffHelper in DiffHelper 5756
• Removed 45 redundant indexes for databases :! 5759
• Back todo-caching added:! 5789
• Reduced the number of projects used in todo list requests :! 5791
• SVG images larger than 2 megabytes are no longer displayed, which reduces loading time and memory usage :! 5794
• Fixed memory leak issue in Markdown sanitization filter:! 5808
• Changed the display of the drop-down menu showing the list of projects to which you can move the ticket - now paginal output is used instead of displaying the full list :! 5828,! 5686
• Removed calls to methods responsible for finding unnecessary Git blobs:! 5848
• Added asynchronous loading of drop-down menus for branches in cherry pick and revert dialogs !! 5607
• Improved queries used to mark todo as completed :! 5832
• Gitlab_git has been updated to version 10.4.7 to use the improvements introduced in this version of the library :! 5851
• Improved Git access checks in Enterprise Edition :! 647
• Removed unnecessary geo_nodes table index geo_nodes 639
• Ace Editor is now loaded only when needed, which reduces the size of the used JavaScript by almost 100 kilobytes :! 4914

New features

• Sidekiq now caches some transaction objects. This option is enabled by default, it can be disabled via the environment variable :! 5054
• Now GitLab can use ruby-prof when processing requests, saving the profiling data to disk for later viewing. To use this feature you need to define a token in the header :! 5281
• Added the ability to track custom events using GitLab Performance Monitoring. For example, the number of pushes, forks of projects, etc.: ! 5830

Instrumentation

• Nokogiri instrumented:! 5470
• Reduced unnecessary burden on instrumentation of method calls :! 5550
• Instrumentation of the class Repository :! 5621
• Instrumentation Gitlab::Highlight 5644
• Project.visible_to_user re-instrumented Project.visible_to_user 5793

GitLab Mattermost 3.3

GitLab 8.11 comes with the Mattermost 3.3 , the open analog of Slack .

Localization to Chinese, Korean and Dutch, Go bot ,
the ability to flag (flag) posts, mentions of the form @here and much more.

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

Redis Sentinel Support

GitLab now has experimental support for Redis Sentinel.

All the details in the documentation

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.11 will require downtime due to database migrations

The downtime for the GitLab.com website (the largest GitLab instance we know) was 15-30 minutes. Depending on the amount of data on your instance, your downtime may be less.

One of the migrations deletes several columns in several tables (and the GitLab instance needs to be minimized so that these data are not lost in the process of accessing them).

Two other migrations create new tables and fill them with information based on the data already existing in the system: in this case, downtime is needed so that the data added does not change during the migration process (and remain unchanged until the 8.11 deployment is complete).

Finally, another migration adds two foreign keys (foreign keys), and here downtime is needed to ensure that there is no simultaneous access to the data being changed.

Obsolescence (deprecation) Ruby 2.1

With this release we updated Ruby to version 2.3.

For manual installations, we strongly recommend that you upgrade to Ruby 2.3. GitLab installations made via Omnibus will automatically use Ruby 2.3.

Ruby 2.1 and 2.2 support will be completely discontinued in GitLab version 8.13.

For those who have updated before the rest

If you upgraded to 8.11 right after the release and got the error undefined method merge! for nil:NilClass undefined method merge! for nil:NilClass , then download a newer package with a lower version .1: 8.11.0-ce.1 .

Just run apt-get update and apt-get install gitlab-ce / apt-get install gitlab-ee , and everything should be fixed by itself.

Forced two-factor authentication using GitLab API and Git over HTTP

If you have two-factor authentication enabled and you try to get an API token via the /sessions or Resource Owner Password Credentials flow provided in OAuth2, then you will not be able to log in. For a successful login in these cases, you will need to use a Personal Access Token.

Read more about personal access tokens

Reindexing Elasticsearch (only for EE)

We have changed the structure of Elasticsearch indexes and now they use parent-child relationships. This improves performance, but requires a complete restructuring of all Elasticsearch indexes. After upgrading to 8.11, you will need to manually remove old indexes and build new ones.

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

 curl -XDELETE 'http://localhost:9200/_all/' 

To rebuild indexes follow the steps described in the documentation for integration with Elasticsearch

Warning The above is applicable only if you are upgrading from a previous version (8.10). If you are upgrading from earlier versions, check the “Upgrade-barometer” sections for all intermediate versions.

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. 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 you will be updated, update immediately on 8.11.2

PPS Chebureque , nick_volynkin and @ sgnl_0 worked on the translation