GitLab 8.15 released

In the last release of the outgoing year, we complete our Master Plan and want to show you something interesting from what we have worked on.

In GitLab 8.15, the Auto Deploy feature appeared - an automated setting for deployment and review applications (Review Apps). For a project on Ruby on Rails, this setting will take less than a minute. See how it works in the video at 1:42 .

In addition, access to your environments (environments) has become faster and easier: through the terminal directly in GitLab (ibid 5:18 )

We want to give everyone the opportunity to use the full power of containers (containers), continuous integration and deployment (continuous integration and deployment, abbreviated CD / CI), applications for review (review apps) and container planners (container schedulers). In GitLab 8.15, we took on all the hard work of setting up, and it all happens completely transparent. In the demo video, we set up and deploy a Ruby application with review apps, several environments, and chatsups (chatops, infrastructure management through chat integration) to a Kubernetes cluster in about 12 minutes. Without GitLab, this task usually takes days, if not weeks.

For most of us, December is the month of holidays and gifts. GitLab also received a lot of new features.

Father Christmas MVP of the month - Michael Munch , who integrated a beautiful display of mathematical formulas (LaTeX) into GitLab. Michael worked on this functionality for more than six months in several merge requests with more than three hundred comments.

We also want to thank Warren Postma for his help in our task tracker and on the community forum and in general for promoting GitLab .

Another gratitude is to Elan Ruusamäe and Dirk Hörner for their contributions to technical design and the implementation of features that greatly strengthened git hooks in GitLab.

Thank you, Warren, Michael, Elan, and Dirk!

Auto Deploy (Auto Deploy)

We want to set up a full-featured CI / CI pipeline (CI / CD pipeline) with deployment through the container scheduler to everyone. It should be easy to learn, but scalable and transparent.

Auto Deploy allows you to configure this. A new button will appear in your project, by clicking on which a merge request (also known as pull request) will be created with the template file .gitlab-ci.yml , containing the deployment script to the container scheduler you are using with Docker. Also in this template there is a Review Apps setting, so you can see the work of the new feature right away - even before you accept the merge request.

This is perhaps the fastest way to deploy in one click of a button, in which the implementation is transparent, all settings are stored in git, and it’s easy to work with all of this in a team.

The Auto Deploy setting in GitLab 8.15 is shown in the video at 1:42 .

This is the first iteration, and so far only a template is available for deployment to an external (external) OpenShift cluster. We use Herokuish and Heroku Buildpacks to package your application in a docker image and deploy it to Kubernetes on OpenShift. In the future, we plan to add support for other container planners and cloud platforms (such as the usual cluster Kubernetes, Mesos and Docker Swarm). We look forward to your contribution to the collection of templates .

For more information, see the documentation for Auto deploy .

Web terminal

Imagine the situation: in your GitLab, several dynamic environments are created and run on demand from a project. These can be applications for review, staging, or production-environments. Usually to get direct access to them you need to put extra effort. This is an annoying limitation: it is useful to do something with your own hands for the sake of experiment or for debugging.

With a web terminal (web terminal) this task is greatly simplified. Just go to the media page of your project and click on the terminal button. GitLab itself establishes an SSH connection with the desired host and provides you with a full console in a browser window.

In the demo video, the web terminal is shown at 5:18 . We look forward to feedback on how this feature has helped you speed up the work.

Detailed information on setting up and using the web terminal is in the documentation for system administrators and in the user documentation on working environments (environments) .

Improved Bitbucket import

Bitbucket import has become even more flexible.
In GitLab 8.15, we added the import of pull-requests, along with comments to the merge-requests of GitLab, as well as the import of milestone (tags of large stages of development, which mark common tasks) and wiki pages.
In total, the following list of imported objects is obtained:

• Repository description
• Git repository itself
• Tasks and comments to them
• Pull Requests and Comments
• Milestone's
• Wiki

When importing, all references to pull requests and tasks, as well as access levels (public or private) are retained.

Read more about importing from Bitbucket in the documentation.

Global git-hooks

GitLab provides the ability to use git-hooks to apply certain rules and triggers for guns and their contents. However, until now the only way to standardize these rules between projects was to copy them into each new project.

With the addition of global hooks, it became possible to create git-hooks that will be used for each project in the GitLab instance. This should simplify the application of uniform rules for all new code.

Create hooks in the hooks/<hook_name>.d/ or specify the GitLab Shell path to the directories with them.

Custom Hook Documentation

Ordered custom git-hooks

When creating custom git-hooks, the order in which they are applied may matter: if a certain hook is not executed, there is no point in trying to do the next. Ordered hooks are executed in lexical order and terminate when all of them fail.

For example, when creating hooks 1-hook.sh and 2-hook.sh , 1 will always be executed before 2 .

This innovation enhances the functionality of hooks and adds opportunities for customizing the processing of incoming commits.

For more information on this topic , see the git-hooks documentation .

Thanks to Elan Ruusamäe and Dirk Hörner for their help in developing and implementing this functionality, as well as global git-hooks!

User Access Level Redefinition for LDAP Groups (EE)

In GitLab EE, it is possible to synchronize LDAP groups with GitLab groups, thus assigning all users of a group a certain level of access. For example, you can assign all users in the LDAP developers group the developers access level. Thus, when new developers are added to the LDAP group, they will automatically receive the appropriate level of access.

GitLab 8.15 extends this functionality. Now, in addition to automatic synchronization of access levels, it has become possible to redefine it for a specific user. This innovation simplifies the management of access levels between groups and projects.

Slack chatops

In version 8.14, we added Chatops to GitLab through integration with the Mattermost , and now we do the same for Slack! That is, now you can create, show and search for tasks directly from Slack, which makes it easy to move from the discussion of the task to the design of it in the tracker.

In addition, it is now possible to deploy to / from any environment. For example, when you enter

 /awesome-website deploy from staging to production 

GitLab will deploy the last commit from staging to master.

Chatops for Slack can be configured in project properties. As always, we welcome user input to the development of chat integration with GitLab.

Configure Mattermost with one click

The integration of GitLab with the Mattermost is greatly simplified. This is now done with one click, as shown in this video at 3:16 .

Integration with Mattermost and Slack allows you to create, show and search for tasks, as well as to deploy to any environment.

Chatops integration documentation with Mattermost

Diffs in letters with notifications

As you know, when someone comments on your diff, an email is sent to you with a notification. Now a part of this diff is added to such letters so that you immediately have a context before your eyes.

Interface improvements

We have made serious efforts to simplify the user experience with GitLab. As a result, this release contains many changes that make working with GitLab even more enjoyable.

Font Update

In order to improve readability and support of various operating systems / browsers, GitLab now uses system fonts. These fonts are optimized for specific platforms, so working with GitLab is equally comfortable, no matter where you do it from.

For clarity, you can see the original Merge-requisition .

Reduced interface pixel width

To improve readability, the maximum width of the task container and merge-requests is reduced. This is only the first step in the process of reducing the enormous length of lines that can be observed throughout GitLab. The progress of work on this task can be observed in the corresponding ticket .

Unique label view

Changed the appearance of labels, now they are more visually different from the buttons. We are continuing to work in this direction in order to make labels and status icons even more distinguishable and recognizable in future versions.

Improved scrolling and loading of assemblies

Scrolling and loading assemblies now works better and looks like:

Smaller page size

Having made system fonts and improved autocompletions, we have significantly reduced the size of all pages in GitLab. This merge-request in the GitLab CE project instead of 1800 Kbytes now occupies 718 Kbytes!

Improved tips for blank pages

To help new users learn GitLab, we have added informative and fun tips for many blank pages throughout the application.
Take a look at our meta ticket to find out where we posted new tips, and feel free to offer yours!

Other changes and amendments

• Improved accessibility: added focus to dropdown options
• Added hover actions to our main navigation and tabs throughout the site
• Improved hover action, focus and active state for buttons ! 7797
• Added hover action for items combined with tickets or Merge Requests menu ! 7777

Mathematics support for Markdown and AsciiDoc using KaTeX

In the comments and files of the repository, you can now accurately draw up mathematical data using the KaTeX library from Khan Academy.

To make inline math formulas, use dollar signs around the line code: $`a^2+b^2=c^2`$

To style multiline math expressions, use the math language for a code block:

 ```math a^2+b^2=c^2 ``` 

This works not only with Markdown, but also with AsciiDoc documents. Read the math support documentation.

For this feature, thanks to Michael Munch.

Merge messages have become cleaner

In previous versions, messages of merges of mergey consisted of a title, a description of a merge request, and a link to a merge request. This is hard to read when using git log and similar functions, since the descriptions of the merge requests often contain requests for reviews, screenshots and other details that are not essential for changing the code.

Now the message of the default commit is as follows:

 Merge branch '$SOURCE_BRANCH' into '$TARGET_BRANCH' $TITLE Closes $CLOSING_ISSUE_REFERENCES # only present if the MR closes issues See merge request $MERGE_REQUEST_REFERENCE 

The previous default message is available in the merge commit message settings.

Thanks to Gabriel Gizotti!

Concise cross-project links in GitLab Flavored Markdown

Previously, references to something in another project always included a namespace, even if the project was in the same namespace.

Short links are now available. Inside the project
gitlab-org/gitlab-ce you can now refer to task number 1 in the GitLab Workhorse,
by writing gitlab-workhorse#1 instead of gitlab-org/gitlab-workhorse#1 ,
saving valuable time at keystrokes!

More information in the special section on GitLab links in our Markdown documentation.

Thanks Oswaldo Ferreira!

Creating a ticket from an unresolved discussion in a merge request

In version 8.14, we added the ability to block merge when there are unresolved discussions .

Now we have added the ability to create a new ticket from an unresolved discussion in a merge request , and at the same time allow this discussion. This is useful in cases where you need to merge something new, but do not want to forget about the comments from the review code.

Thank you Bob van Landuyt!

Manual actions from the pipeline scheme (CI)

Manual actions allow you to request manual interaction before moving to a specific task in CI. Your entire pipeline can work automatically, but you need to make a click directly for production deployment.

This can be done directly from the pipeline scheme. You just need to click on the “Play” button to start a specific task.

User action API

So that you can quickly understand when the user last used GitLab, we added a special administrative API to GitLab. It allows you to get the timestamp of the last activity of any user in the instance.

Find out more in the documentation.

Sort project or group members

Now it will be easier for you to find people in projects and groups by sorting by name, access level or date of joining.

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

Translation from English is made by translational artel "Nadmozg and partners", http://nadmosq.ru . Worked on the translation nick_volynkin , rishavant and sgnl_05 .