GitLab 8.14 released

Imagine that you are reviewing the code for a new feature. In addition to the quality of its code, you are also interested in how it will look and work in your product and how convenient it will be to use it. Previously, you would have to interrupt the development process on your own working machine, checkout on the branch being checked, carry out the necessary database migrations and run the entire working environment (development environment) necessary for the application. Now it will be enough for you to enter the merge-request of this branch on GitLab. There will be a link to an already running application, deployed in a separate environment.

Finally, the review is complete, and you give your colleague feedback in the chat. Instead of deciding which of you will start a new task in the tracker, you can create a task and estimate the time for its development without leaving the chat. The analytics of the development cycle (cycle analytics) will immediately take into account this assessment and will show you the entire path of the task before being released to production, reporting possible bottlenecks.

All this and much more is possible in the new version of GitLab 8.14. It features time tracking, review apps, chat commands and new analytics features in the development cycle.

This month's MVP is Toon Claes. He implemented a button to delete at once all the branches lost in the master .

Thank you, Toon!

Time Tracking, Beta (EE)

Considering the time spent on a task is not an easy task. The results of this calculation are needed both by developers who receive an hourly wage, as well as by managers who analyze the expenditure of resources on tasks and projects. Many tools are used to record time, but usually they are not integrated into the development process.

Time tracking in GitLab allows you to record the time spent on a task directly during work.

Using the slash command /estimate task is assigned a time estimate. The same team can change the assessment at any time. Recall that the slash commands are written in the task description or in the comments, they are executed when they are saved and are not displayed in the received text.

 /estimate 6h 

After you have worked on the task for a while, you can consider it using the /spend command:

 /spend 3h 

This will be immediately reflected in the interface:

Time tracking will be available to all our customers with Enterprise Edition in trial mode during the beta testing period, after which it will become a separate paid product .

We look forward to your suggestions on how time can be improved so that it will be useful to you. Please publish them in the task tracker or write in the comments to this article.

For example, we think about the implementation of reports , APIs , time tracking on task boards and various other features .

Time Tracking Documentation

Chat commands (experimental feature)

It seems that in the last couple of years the discussions have moved from negotiations to online chat rooms. Chats help teamwork, and it is in them that new ideas are born. This is an important part of the concept “from idea to implementation” (idea-to-production), which we strive to implement in GitLab. Chat teams associate it with other GitLab features: repositories, task tracker and CI / CD pipelines.

Now the development of chat teams has passed only one iteration, but the ability to quickly create and view tasks has already been implemented. Here is an example of a command that creates a task with a title and description:

 /gitlab issue create         ! 

If you enable ChatOps, you can use chat to manage your production deployment (of course, you need an account and corresponding rights):

 /gitlab deploy staging to production 

In the current iteration, support for chat commands is implemented for the Mattermost, which comes in the GitLab Omnibus package. Support for Slack will be added soon. The set of commands is limited for now, but we are going to expand it and we will be glad to receive your feedback.

For details, see the chat command documentation.

Review Apps

Review Apps is a new word in the code review procedure. Instead of simply viewing the code, Review Apps provides a complete environment in which your application runs, with the ability to test and make changes on the fly.

Experimental support for Review Apps was published in GitLab 8.12, an improved version was added to GitLab 8.13, and finally, a full-fledged final version of Review Apps is delivered with version 8.14.

Now the Review Apps application is automatically launched for each branch and is destroyed when it is deleted. We use this functionality with the official GitLab blog , and it shows itself perfectly. The features of Review Apps are so impressive that we wrote a separate post about them.

Introductory post about Review Apps

Review Apps documentation

Cycle Analytics Events

With Cycle Analytics, you can monitor how quickly your ideas reach implementation in the final product, as well as where they get stuck along the way. In order to add clarity, the latest events of each stage will now be displayed.

The introduction of this functionality allows you to easily track what is happening at each stage, as well as quickly detect and eliminate the causes of the slowdown.

Cycle Analytics Documentation

Prohibition of merge until the end of the review

It is not necessary to carry out the merge code to successfully pass all the tests and the end of the review. In GitLab, it has been possible for some time to ban Merge before passing the tests, but until recently the same could not be done with regard to revision code.

Starting with GitLab 8.14, you can disable merge code until all discussions in the merge request are closed. Now it is impossible to accidentally overlook the last comments at the bottom of the page (although for this we have a beautiful widget at the top); Only the verified and verified code will go into production.

Enable this option in the project settings.

Thanks to Rodolfo Arruda for implementing this great feature!

Merge Requests Discussion Documentation

Deleting all spawn branches

Toon Claes has implemented a seemingly obvious, but for some reason, the still missing feature is a single button for deleting all the branches in GitLab.

When clicked, confirmation of the action is requested and, if agreed, the process of deleting branches is launched. This button is located in the Repository Branches section.

This will not remove protected branches.

Thanks Toon Claes!

Subscribe to group tags

Group tags have been added to GitLab 8.13, and from the current version there is an opportunity to subscribe to them. With this, you can receive notifications about events of interest to you in the scale of groups. For example, it became possible to receive notifications when creating a new task with a customer tag, as a result of which you can easily track all tasks with such a tag in all projects within the same group.

Improved mail pipelines alerts

In the event of a pipeline break, you will be sent a letter containing the reason for the fall. So now there is no need to immediately go into the logs in order to understand whether you need to immediately assemble the whole team or simply restart the assembly.

JIRA integration improvements

We know that many of you are actively using JIRA. We are working hard to improve its integration with GitLab. Below are some of the changes we made in this release. We would love to hear your suggestions for other improvements.

Read the revised JIRA integration documentation.

Remote references related to tasks in JIRA

The connection of tasks in JIRA with commits in GitLab has become even easier. When you mention a JIRA task in a commit or a merge request, a back link to a commit or request is added to this task. You can write that he Fixes task in JIRA or just mention it - be sure all links will appear as it should.

Merge-Request: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7413

A more "silent" interaction of GitLab and JIRA

When you configure the integration of JIRA and GitLab, by default every commit and merge request in GitLab that refers to a task in JIRA creates a comment in this task in JIRA. Some people like to be aware of all the details of what is happening, others prefer a quieter job.

In GitLab 8.14, you can prohibit the creation of comments when referring to a task in JIRA in a commit or merge request.

Superior view

GitLab in version 8.14 has become prettier and easier to use. Below are some changes:

Now you can see who you mention:

Conveyors and meta-information look better than before:

Now we show the environmental information on the build page:

Conveyors now show when specific builds are skipped:

It's easier to see what's left in the current pipeline:

Improved accessibility

Our wonderful UX and frontend teams have worked hard to improve the availability of GitLab. The most prominent changes this month are:

• We added the “Skip to content” button when pressing Tab to navigate through different active objects on the web page ... This will allow you to quickly get to the content and skip the navigation parts.
• All drop-down menus, buttons, and anchors are now visually highlighted when you navigate through them with Tab.
• We increased the contrast between the background and the anchors.

We are always happy to hear your suggestions for improving the availability of GitLab.

Support for private container registries in GitLab CI assemblies

In GitLab 8.14 and GitLab Runner 1.8, we have improved support for private docker images.

Now you can use private / protected images that are automatically saved in the GitLab Container Registry without any changes. GitLab will send registry credentials with the build data, and Runner will use them to authorize Docker’s pull requests.

You can also use the protected variable DOCKER_AUTH_CONFIG to add credentials for other private registries. Because of this, you can use any image from any registry — public or private — that is accessed from the build host so that this image becomes the base of your build or service it uses.

Runner 1.8 also fixes the alias generation mechanism from the service name when the registry is available on a non-standard port.

You can read more about supporting private container registers in the GitLab Runner configuration documentation .

Detailed release notes and instructions for updating / installing can be found in the original English post: https://about.gitlab.com/2016/11/22/gitlab-8-14-released/

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.