GitLab 8.13 release

We travel the world and are very happy to meet with our users.

This month, we are proud to present you a lot of innovations that you have asked us both personally and through our task tracker .

Now it is possible to create several problem boards (issue boards), and being on the page of the board - to quickly start new tasks. The life of merge conflicts has become even harder and more transient, because now they can be resolved directly in GitLab. Improved Cycle Analytics makes it even easier to keep track of which version of the code is running in each of the environments (environments), and also provides you with instant feedback.

This month’s MVP is awarded to Marc Siegfriedt for his contribution to the creation of an entry point (endpoint) API for committing several files at once. Mark showed patience and perseverance in working on this difficult merzh-requester. Thank you, Mark!

Multiple task boards instead of one (EE)

Now there can be several task boards in each GitLab Enterprise Edition project.

This allows you to manage multiple workflows, as tags on tasks are updated synchronously on all boards. For example, you have a task board for the entire company and a separate one for the design team. When the design team performs its part of the task and passes the task to the front end team, both boards are updated.

We look forward to your stories about how to use the task boards.

Creating new tasks directly on the task board

When viewing the taskbar, you can quickly add one more to any list:

Of course, she will immediately receive the appropriate labels.

Merge conflicts editor.

In GitLab 8.11 , the resolution of merge conflicts appeared, which allows, when resolving a conflict, to choose between the option from the current branch and the one that merges into the current one.

GitLab 8.13 introduces a new conflict resolution tool. Now you can edit conflicting changes directly in GitLab. In other words, almost any conflicts can be resolved without leaving the browser page.

We hope this helps you to be all the pain of merger conflicts like a bad dream.

Group tags

When you have one organization and several projects, it is often necessary to create identical labels with the same prioritization on several task boards at once. This is a pretty boring job.

To simplify it, we implemented group labels. They work in the same way as regular ones, but they are created and configured once for a group of projects, and then they are available in each project.

At the moment, you can create group tags only from the page of your group. In the future, we will be able to convert existing project labels into group tags.

Ability to stop Review Apps

Review Apps allow you to deploy the code of any commit in a full working environment for review and testing. Now that this environment is no longer needed, you can stop it directly through the GitLab interface.

Links to deployed code versions

GitLab creates special links (ref) for code versions that are currently deployed on each of your environments. You just need to set up your local repository once to update these links with a simple git fetch .

Conveyors to view commits

Now, on the commit page, we show the corresponding pipelines, which allows us to immediately see what was happening with each of the commits.

Cycle Analytics Improvements

Cycle Analytics behavior has been changed - now all activity is measured for a certain period of time, and not just sent to production. Of course, the staging and production stages show only what was sent to production.

Assignment of tickets to the author of a merge-request

You specified links to certain tickets in your commit or merge-request, but did not assign them to yourself or to the author of the merge-request? Now there is an easy way to do this:

Limit the visibility of the project repository

Now it is possible to restrict access to the project repository, in addition to the existing functionality of restricting access to tickets (issues) and snippets of code (snippets). Now you can remove access to the repository for everyone at all, or leave access exclusively to team members.

Slash command / wip

Now you can use our wonderful slash commands to quickly change the status of a merge request from / to Work-In-Progress (WIP).

Just enter /wip and confirm sending your comment or description of the merge-request.

CI debug tracking

By default, GitLab Runner does not display most of the information about the process of working with tasks. This approach prevents the redundancy of assembly logs, as well as secret information, unless it is output to the console using a script.

On the other hand, because of this, it is difficult to establish the reason for the incorrect performance of any task. In this situation, you can enable debug tracking in .gitlab-ci.yml , this option is available in GitLab Runner starting from version 1.7. It includes a trace of the shell, as a result of which information about the execution of all commands, assigning values ​​to all variables, etc. is added to the build logs.

Before connecting this option, make sure that only team members can view the build logs. Also, do not forget to delete all the generated logs before re-opening visibility to everyone.

To enable debug tracking, set the variable `CI_DEBUG_TRACE to true:

 job1: variables: CI_DEBUG_TRACE: "true" 

For more information, see the debug tracking document.

Disabling Git operations in CI

Now it is possible to disable Git operations to speed up builds that do not require interaction with the repository. To do this, you need to specify the Git strategy in the .gitlab-ci.yml :

 variables: GIT_STRATEGY: none 

You can read more about Git strategies in CI in our documentation.

Date of deployment in Merge Requests

A small but pleasant innovation - now the date of deployment is indicated directly in the merge request.

Gitlab runner

Also, GitLab Runner 1.7 was released along with GitLab 8.13. List of the most interesting changes:

• Added use of Go 1.7 - adds support for Runner on Mac OS X Sierra ! 323
• Added GIT_STRATEGY = none ! 332
• OffPeak autoscale support added ! 345
• A variable was introduced to enable shell tracing in bash, cmd.exe and powershell.exe ! 339
• The InCluster config is loaded first, if the boot is unsuccessful - the kubectl config ! 327
• Godep: github.com/Sirupsen/logrus updated to version 0.10.0 ! 344
• Added use of git clone –no-checkout and git checkout –force ! 341
• The runner field value is now converted to lower case for compatibility with GCE restrictions ! 297
• Added before_script processing when exec command exec ! 355
• Builds are no longer flagged as failed due to a caching error ! 359
• Improvements in the registration procedure ! 356

A complete list of changes can be found in the Runner changer .

GitLab Mattermost

GitLab 8.13 includes the Mattermost , an open source alternative to Slack, available on the web, desktop and mobile devices and integration with more than 700 applications using Zapier . This month added integration with Slack, Gitter, XMPP and IRC . Mattermost is now updated 6 times a year ; New updates are added to GitLab a month after they are released.

API innovations

This release includes several new APIs:

Committing multiple files at the same time

Thanks to MVP of the month, Mark has the opportunity to commit several files via the API at the same time.

API documentation for this topic

Task board interface

Andre Guedes has implemented a full-fledged task board API. Thanks, Andre!

Information about user actions

Using the API, you can now get information about changes made to a project by a specific user.

Documentation on this topic

List of visible projects

Thanks to Ben Beckel (Ben Boeckel) the opportunity to view a list of all projects visible to you through the API.

More information in the API documentation.

Performance changes

CE changes:

• Improved display performance of the group milestones page:! 6457
• Reduced the number of requests performed when processing Markdown links:! 6457 and ! 6545
• Sidekiq now uses a pool of links when working with the Rails cache:! 6468 and ! 6657
• Reduced the number of updates to the ci_runners table, thereby reducing the number of database calls ci_runners 6537
• Slightly reduced the number of queries executed when pushing commits:! 6680
• Added a daily preliminary calculation of the project rating for the trending projects page, which improves its performance:! 6749
• Added asynchronous loading of diffs when creating a new merge-request:! 5844
• When you change the timestamp of recent project changes, temporary leases are no longer used. Redis:! 6678
• The secret token for gitlab-shell and API is now stored in memory, and not read from disk with each API request :! 6599
• Reduced the number of requests used when checking project policies :! 6442
• The Worker used for expiring build artifacts now distributes tasks more efficiently and uses more efficient SQL queries :! 6732
• Updates on Merge Requests using push now use a special Sidekiq worker:! 6767
• CI pipeline hooks are now updated asynchronously :! 6824
• CI pipeline metrics are now updated using Sidekiq worker :! 6896
• Improved performance and memory usage of the GitHub bootloader:! 6552
• Optimized getting URL for drawing emoji in discussions .: ! 6848
• When creating a project, we automatically create the corresponding project_features string instead of checking this (and creating a string if necessary) whenever we request a project from the database. This reduces the number of database requests when we need to return a project from version 2 to 1 :! 6908
• The CI pipeline commits are updated only after creating the pipeline instead of updating each separately :! 6986
• The CI pipeline lengths are updated only at the end of the pipeline instead of being updated after each state change :! 6987
• Project cache refresh now happens every 15 minutes. The statistics can become stale (for example, counting commits), but the load on the disk will be significantly reduced :! 7017
• Sidekiq now uses different queues for a large number of different employees:! 7006
• The tasks in the CI pipeline are distributed smarter, preventing the assignment of several tasks with the same parameters at the same time :! 7005
• Caching markdown fields in database ! 6095

Changes in EE:

• GitLab usage data is now cached:! 779

Gitlab-shell changes:

• Git performance tracking can now be enabled using the environment variable:! 91
• Improved repository movement between shards:! 97 and ! 96

Omnibus GitLab Package Changes

• Jemalloc is now used as the default memory allocator, which should reduce the amount of memory used.
• Batch NGINX now has a Status method enabled by default. Thank you Luis Sagastume!
• New configuration options added to gitlab.rb

Other changes

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

Update barometer

This release contains a significant number of migrations that require downtime. Administrators must be prepared for at least 30 minutes of inactivity. Small installations (for example, with several hundred projects) should complete the migration process in 5-10 minutes.

Remember that these time estimates are approximate and may vary depending on your situation.

Some of the migrations are:

• add foreign keys to existing tables
• move Sidekiq tasks from one queue to another
• remove duplicate labels
• prioritize labels
• do other data cleansing

Sidekiq Queues

This release made several changes to Sidekiq. Previously, GitLab used a limited number of queues, which was strictly defined in bin/background_jobs and in Omnibus GitLab. Starting from version 8.13, all queue names used are in config/sidekiq_queues.yml . Users using bin/background_jobs to launch Sidekiq or Omnibus GitLab no longer need to do anything manually. Users running the installation from source may need to make changes to the settings to make sure that Sidekiq is using this configuration file. To do this, they need to make sure that Sidekiq runs as follows:

sidekiq -C path / to / gitlab / config / sidekiq_queues.yml

If you are using a custom sidekiq configuration file, you need to add the contents of sidekiq_queues.yml to this file (and keep it up to date) or use sidekiq_queues.yml and define custom settings using the command line interface for the sidekiq .

This configuration file also determines the weight of each queue. The load on Redis will increase slightly, but Sidekiq now more equitably distributes the work instead of processing the queues in order. Queue names and priorities can be customized by the user.

Something else

We assume that you are updating from the latest version. If this is not the case, check out the barometers of updates for intermediate versions that you are missing. If you are upgrading from GitLab version to 8.0 and you have CI connected, 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 the 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 was done by the translation agency “Nadmozg and Partners”, http://nadmosq.ru , nick_volynkin , rishavant and sgnl_05 worked on the translation.