GitLab 10.3 released: static application security testing and browser performance testing

In this release, we have added new ways to make sure that the changes made to the code will be safe and will not lead to a drop in performance, improved planning and collaboration processes, assembly and release.

Security and Testing

Not so long ago, we announced the ambitious project Complete.
DevOps , and in this release we added several features that contribute to its implementation. Static application security testing and browser performance testing add security and performance checks to the CI / CD pipelines, respectively. Security testing has already been added to Auto DevOps, performance testing will be added soon.

Discussions and collaboration

Version 10.3 includes a discussion of commits in merge requests , which makes it possible to create discussions of individual commits directly in a merge request.

Thanks to our MVP , it is also possible to edit the name of the branch when creating a merge-request from the task . Now you can quickly create merge-requests directly from tasks without breaking the branch creation algorithm.

Sometimes a picture can say more than a thousand words. In version 10.3, we added support for flowcharts, sequence diagrams, and Gantt diagrams in GitLab Flavored Markdown (GFM) with Mermaid.

Build and release

GitLab 10.3 adds support for several Kubernetes clusters in a project , which allows you to isolate the final (production) cluster from development and testing clusters.

Also in version 10.3 added improvements to Auto DevOps. Now, when Auto DevOps is connected to the project, the first pipeline will start automatically .

Artifacts can be removed both manually and automatically after a certain period of time. We added strict artifact dependency checks to ensure that CI / CD work is not performed if the necessary artifacts have not been found.

Do not miss the new features.

GitLab 10.3 also adds improvements to Merge Requests, Epic, Mailstore, Mirroring Repositories, Interface, Geo, Runner, Protected Branches, Quick Actions, and Task Boards.

Further in the article we will dwell on these and other innovations of GitLab 10.3.

Thank you so much for helping us create great software with GitLab this past year! We wish you a happy new year, full of pleasant surprises! Happy holiday!

We invite to our meetings!

MVP of the month - Vitaliy 'blackst0ne' Klachkov

Vitaly is no stranger to such honors - he was already becoming the release 10.1 MVP. For release 10.3, he added eight Merge-Requests , including the ability to edit the name of the branch when it was created from the task in the web interface and Mermaid support for the Markdown editor .

Thanks (once again), Vitaly!

Static Application Security Testing (SAST) (EEU)

It is difficult to overestimate the importance of the security code of the final product: its vulnerabilities can lead to a whole heap of unpleasant consequences, from system failure to the leakage of users' personal information. Conducting regular security checks avoids such vulnerabilities, even if they affect libraries imported from other projects.

In GitLab 10.3, the static application security testing system (Static Application Security Testing - SAST) checks your code (static analysis) for known security problems that can be used for bad purposes, such as unpatched external dependencies or cross-site scripting vulnerabilities. This system automatically recognizes the most common languages ​​(Ruby, JavaScript and Python are currently supported). The results of her work are displayed directly on the Merge-Request page, so your team will always be aware of potential security problems before merging the code in the master and subsequent deployment. SAST is part of Auto
DevOps , thanks to which this functionality works automatically.

Documentation for static application security testing (SAST) .

Performance Testing in the Browser (EEP)

GitLab already has the ability to track the performance of the resulting application, but, in addition, it is very important to make sure that the introduction of a new code will not lead to a performance degradation. An example of such situations could be adding an uncompressed image or adding a new JavaScript library directly to <head> , which will slow down the page load. Manually searching for such errors can be a time consuming and ungrateful process.

In order to avoid such problems, we added a simple way to analyze the effect of a merge request on the performance of web applications. The performance testing system in the browser functions in a test browser window without a header and simulates the loading of one or several pages of your application with subsequent analysis. The results of this analysis are displayed on the merge-requester page, which provides a vivid illustration of its effect on performance before the merger is held in the master.

Performance testing documentation in the browser .

Merge Requests Discussions (CE, EES, EEP)

GitLab is great for workflows in which teams comment and discuss each new version of Merge Requests.

However, some teams interact at the level of individual commits, even if there are several of them in the push. Previously, it was impossible to implement such a workflow in GitLab.

In version 10.3 we add this feature. Just go to the Merge-Requests commits tab and select the commit to go to the changes tab. With the help of the new interface, it is now possible to start a discussion with the ability to resolve it (resolve) for each commit. Such discussions are also displayed in the standard discussion tab, among others. This innovation does not affect previously available workflows, which allows you to choose the process that is most suitable for you.

Documentation for discussing merge requests .

Editing the branch name when creating a merge-request from the task (CE, EES, EEP)

In GitLab, you can create a merge request and its branch in one click right from the task window. When you click on the button for creating a merge-request, a branch with the same name as the task is automatically created. However, in some situations it is undesirable to assign such a name to a branch, for example, when the name of the task is too long. In this release, we introduce the ability to edit the name of a branch before creating it. This feature also exists when creating a separate branch without a merge request.

Thanks to blackst0ne for contributing to this work!

Documentation on creating a merge-request from the task .

Flowcharts, sequence diagrams, and Gantt charts in GitLab Flavored Markdown (GFM) using Mermaid (CE, EES, EEP)

With the release of this release, you will be able to create beautiful flowcharts, sequence diagrams and Gantt charts in the descriptions and comments of the tasks and Merge-Requests. To create them, use GitLab Flavored Markdown (GFM). To do this, simply use the simple Mermaid syntax, which is now supported in GFM.

Thanks to blackst0ne for contributing to this work!

Mermaid GFM Support Documentation .

Multiple Kubernetes Cluster Support for One Project (Beta) (EEP)

GitLab can easily deploy your application to various environments using the Kubernetes cluster. Often the publication Development, Staging, Production and Review Apps occurs in the same way. Until now, they all existed in the same cluster. However, you may need to distinguish between data and access, for example, if you need to store production data physically elsewhere.

With the release of GitLab 10.3, it became possible to configure for one project several Kubernetes clusters, each of which is associated with a specific environment. Due to this, when publishing your application, the CI / CD pipelines automatically use the necessary cluster.

Documentation for supporting multiple Kubernetes clusters for a single project .

Automatic start of the first conveyor when Auto DevOps is enabled (CE, EES, EEP)

Earlier, when Auto DevOps was connected, you had to wait for the push of the first commit in order for the pipelines to start functioning. This behavior was illogical and not intuitive.

With the release of GitLab 10.3, the launch of the pipeline of your project occurs immediately after turning on Auto DevOps in the project settings, so that you no longer need to push another commit to start the conveyor.

Auto DevOps Connection Documentation .

Strict artifact dependency checks (CE, EES, EEP)

When working with CI / CD pipelines, there are frequent situations in which artifacts are created in one job and used in another. With the dependencies keyword, you can specify which artifacts from the previous steps you need. However, when the works have already been completed, these artifacts may not be available, for example, they may have expired, or they could be removed manually. This can lead to situations in which your code is trying to access resources that are already inaccessible, leading to errors that are rather difficult to detect and debug.

In GitLab 10.3, we introduce rigorous checks for such dependencies. Now the work will not be performed if all their dependencies are not found. Thanks to this approach, you will immediately find out if any necessary artifact is missing and you can take the necessary measures, for example, to launch a completely new conveyor.

Documentation of strict artifact dependency checks .

Restrictions for deleting CI / CD logs (CE, EES, EEP)

The logs of the CI / CD work are stored in GitLab and are available for further analysis by users who have access to the project. These logs can be removed to prevent information leaks or simply to free up space.

Starting from version 10.3, only users with the Master access level, as well as those who have started the corresponding work, can delete the logs of work execution.

Documentation on the CI / CD access model .

Improved integration with existing clusters (beta) (CE, EES, EEP)

Previously, project setup for the use of an already existing cluster Kubernetes took place through the service integration page in the project settings. This approach is at odds with the cluster support approach introduced in version 10.1.

In GitLab 10.3, we added the ability to add existing Kubernetes clusters to the project directly from the Clusters page. As a result, the previous version of the services integration page is now becoming obsolete.

Cluster integration documentation .

Git push and pull when redirecting a project (CE, EES, EEP)

Renaming and moving projects occurs very often. The GitLab web user interface always supported redirecting users to the current location, but this was not the case for Git actions.

Since version 10.3, Git actions also support automatic redirection. Thanks to this, all scripts, automations and Git clients will continue to work properly after renaming a user or group.

Please note that the old way to the repository will be prohibited to use in order to avoid pushing or pulling from the wrong repository.

Documentation of redirection when changing the path to the repository .

Displaying the role of a project member in the project list (CE, EES, EEP)

When working with several projects at once, it is sometimes difficult to remember your access level for each of them. This can lead to unpleasant situations and misunderstanding why some of the project functionality is not available to you.

It is very convenient to have a way to quickly see what level of access you have in order to understand what restrictions you have and to request an increased level of access if necessary.

Now your access level is displayed on the project taskbar next to its name, so you no longer need to go into each project and delve into the list of its users.

Documentation of roles and levels of access for GitLab users .

Customize New Project Page (CE, EES, EEP)

Thanks to Markus Koller, GitLab administrators can now add your own support texts to the new project creation page.

This is a great way to provide users with additional instructions on how to add a new project. Since these fields support Markdown markup, you can link to other pages or additional documentation with more detailed instructions.

<img src = "https://about.gitlab.com/images/10_3/custom_new_project_page.png" alt = "Illustration for Customize„ New Project “page" />

Documentation on setting up the "New Project" page .

Adding users or groups access to protected branches (CE, EES, EEP)

Protected branches allow you to block access to the push or merge to the repository branches, preventing accidental changes in the code or in the workflow.

One of the most important features of protected branches is to identify users or groups of users who have permission to push or merge changes. Now it can be done through the API.

Documentation on protected branches .

Transition to the epic from the task (EEU)

Since one task can belong only to one epic, it is useful when looking at a task to understand whether it already belongs to some epic or not. Now you can easily access the task epic from the task side menu.

Epic documentation .

Attaching Images to an Epic (EEU)

Now you can attach images (or any other files) to the epic through its description. It works by analogy with the task description (and any other fields in GitLab in Markdown markup). This gives more room for describing epic items due to the possibility to add a diagram or layout.

Epic documentation .

Displaying epic links in GitLab Flavored Markdown (GFM) (EEU) markup

References to epics for fields in GitLab Flavored Markdown (GFM) will now be displayed in the same way as links to tasks, merge-requests and other objects in GitLab. In the beginning there is a group path, then & , and at the end an epic identifier. The tooltip displays the name of the epic. Insert the link to the epic in the text field, and GitLab displays it compactly and easy to read. You can also enter a shortcut to the epic directly in the GFM field (for example, gitlab-org&23 ), and GitLab will translate it into a link.

Documentation for displaying epic links in GFM .

Updating task weights from the taskbar sidebar (CE, EES, EEP)

Now you can update task weight directly from the taskbar side menu - just like on the task page itself. This will allow you to manage tasks more quickly and easily when planning and tracking them using the whiteboard.

Taskboard documentation .

Sorting Milestones in the Milestone Group List (CE, EES, EEP)

Now you can sort the Mailstone on the page of the list of Mailstone groups - just like on the page of the list of Mailstone cities. In one of the previous versions, we introduced the group Milestone and are now working to add all the useful functions of the project Milestone group to the group Mylleston.

Documentation for group milestones .

Redesign of navigation in the merge-request (CE, EES, EEP)

Navigating the merge-request diff-file has become easier. Now the file name is displayed on a separate line. And if the file path is too long, only the end is displayed.

Learn more about navigating the merge-request change diff file .

Smart autocomplete for quick actions with tags (CE, EES, EEP)

When using quick actions to add or remove tags to a task or merge-request, the drop-down list of hints greatly helps to quickly find what you need. In the latest version, autocomplete has become even smarter: now when adding a label, the drop-down list does not show already added ones. And when deleting among the prompts, only those tags that are already added are displayed.

Thank you blackst0ne for this opportunity!

Quick action documentation with tags .

Create Merge Requests by Email (CE, EES, EEP)

Some people prefer to do maximum work on PC tools, using the GitLab web interface for tasks that cannot be done without it.

With this release, you will be able to create merge-requests by email, expanding the number of development tasks that you can perform using the available tools. Send a letter to GitLab, specifying the source branch name in the subject line, and GitLab will automatically create a merge request. You can find a special (and unique for you) email of a specific project by clicking on the link at the bottom of the project's merge-requests. It does not change until you manually update it. Therefore, you can safely save it in your email client.

For developers who are developing in the terminal, they work with Git in it and send letters from it: you can now do everything up to the creation of a merge request, without leaving the terminal.

Documentation for creating Merge-Requests by email .

Total Task Time in Mylistone (CE, EES, EEP)

Many teams measure the time spent on work on a specific task. Now it became possible to see how much time was spent working on all the tasks in Mailstone. Take a look at the side menu on the page Milestone.

Milestone side menu documentation .

Only protected branches are mirrored (EES, EEP)

When mirroring the pushes or repository pulls is enabled, all changes will automatically be reflected to the specified Git repository or copied from there. But if there was an altered Git history in one of the pushes (for example, after rebasing), mirroring will not be performed. Usually, no one will relocate key branches — for example, master — but this can happen for a branch with separate functionality.

To prevent such situations, now only protected branches can be mirrored.

Documentation for mirroring repositories .

Starting mirroring of pools through API (EES, EEP)

When mirroring is enabled for the repository, changes from the original configured Git repository to your repository are automatically reflected. Changes are reflected regularly - as soon as they are detected by a survey.

We added a new API for immediate change pool. Mirroring the pool will occur in a matter of seconds after the push push event in the source repository is triggered.

Documentation on how to start mirroring the pool through the API .

Immediate mirroring push (EES, EEP)

When pushing mirroring is enabled, all changes to the repository are pushed to another specified repository.

We changed the limit on mirroring: changes are now instantly fired, but no more than once every five minutes. If mirroring is allowed only for protected branches, the limit drops to one push per minute.

Documentation on mirroring pushes .

Restricted repository mirroring (EES, EEP)

When mirroring the pushes or repository pulls is enabled, all changes will automatically be reflected to the specified Git repository or copied from there.

In GitLab 10.3, administrators can only allow access to the push and mirror mirror for administrators so that the repositories in the instance or from the GitLab instance are not copied again.

Documentation on limiting repository mirroring .

Improved interface for working with Geo nodes (EEP)

Geo node management and tracking has been greatly simplified by splitting the interface into separate parts: for tracking and for adding and editing a Geo node.

Documentation for improved display of Geo nodes .

Simplified PostgreSQL HA (EEP) Setup

In GitLab 10.2, Postgres HA became fully available , which made it easier to set up a Postgres database cluster in production using the Omnibus package.

Now we have made it even easier. We present you new Postgres roles . These roles significantly reduce the number of actions required to configure individual database nodes, automatically turning off all other functionalities and components.

Documentation for simplified PostgreSQL HA configuration .

GitLab Mattermost 4.4.5 (CE, EES, EEP)

GitLab 10.3 includes the Mattermost 4.4.5 , an open source alternative to Slack . The new version includes a beta release of plug-in support and much more.

GitLab Mattermost Documentation 4.4.5 .

GitLab Runner 10.3 (CE, EES, EEP)

Also with this release comes GitLab Runner 10.3. GitLab Runner is an open source project used to run CI / CD and send the results back to GitLab.

The most important changes are:

• Added link Kubernetes executor with a service account; carrier token (bearer token) can be overwritten - thanks to David Schile from Nordstorm's CI team for his contribution!
• Stop the Docker Machine before deleting it.
• Added options --checkout --force to git submodule update --init
• Fixed adding <nil> to the end of syslog logs
• Corrected the behavior of the Kubernetes executor in declaring overwritten variables
• Added zip archive for Windows release files

Full list of changes in CHANGELOG GitLab Runner .

GitLab Runner Documentation 10.3 .

Omnibus Improvements (CE, EES, EEP)

• Added additional warnings for outdated settings; they are now displayed in red
• gpgme 2.1.15 Omnibus GitLab,
• Git 2.14.3
• Docker Registry 2.6.2
• Redis 3.2.11

Documentation on Omnibus improvements .

(EEP)

, GitLab Enterprise Edition. . , .

, .

- , .

.

Performance Improvements (CE, EES, EEP)

, . , GitLab, GitLab.com, .

GitLab 10.3 24 -, CI/CD, Prometheus, . :

• Wiki-, , Wiki-
• ,
• -
• ,
• Projects::MergeRequestsController#show.json

.

release notes / : GitLab 10.3 released with Static Application Security Testing and Browser Performance Testing .