GitLab 11.3 released with Maven repository and protected environments

Original author: GitLab
  • Transfer

Picture to attract attention

With the new release of GitLab 11.3, we are pleased to introduce support for Maven repositories, Code Owners, protected environments and predictions for epics. All this will help automate the management of environments and code that will allow Java developers to be even more efficient.

Maven repository

We have expanded our support for Java projects by integrating Maven repositories directly into GitLab. Java developers will appreciate a safe and standardized way to link Maven libraries with a version control system and will be able to save time by reusing these libraries in other projects. This feature is available with GitLab Premium.

Code Owners and Protected Environments

In paid plans starting from GitLab Starter, it became possible to assign code owners to a file , specifying the team members responsible for this part of the code. This is preparation for future releases, where internal control over the code level will be strengthened.

Starting with GitLab Premium, operators (responsible for deployment) can also use protected environments to set permissions that determine who can deploy the code to production. This will significantly reduce the risk that someone will send code that should not have been added. And, in principle, increase the safety of the environment.

Predictions for epic

Portfolio Management appeared in GitLab Ultimate, which will automatically predict the start and end dates of the epic , based on the timing of tasks in the Milestones. Thanks to this innovation, portfolio managers will be able to match the planned start and end dates with work planned for the Milestones, getting an idea of ​​the potential backlog within the framework of the epic. This will allow you to quickly decide what you will manage to complete, and when it is worth adjusting plans.

Everyone can contribute

Many of these changes were made by the huge GitLab community. We look forward to your feedback and improvements for these new features. Together we are a great team!

Let us know what you think, in the comments to the blog article - and on Habré too. What do you expect from this release? What should we continue to work on?

We invite you to our meetings and to the webcast of the 11.3 release .

GitLab MVP badge

This month's MVP is George Tsiolis

George added a very popular feature that many have asked to add: users can now include their private development contributions on a timeline on a profile page.

Thank you, George, for your continued contributions to improving GitLab, soon you will get a cool set of merch!

The main new features of the release of GitLab 11.3

Maven repository


For software companies, it’s very important to have a simple and secure way to manage dependencies. Package management tools, such as Maven for Java developers, provide a standardized way to distribute libraries and manage their versions among projects.

In release 11.3, we are happy to provide support for Maven repositories that are built directly into GitLab. Developers of low-level services can now publish their libraries in the Maven-project repository. They will only have to share a simple XML snippet with other teams that want to use this library, and Maven with GitLab will do the rest.

Take a look at a test project that pulls the build into the GitLab Maven repository and see how easy it is!

Maven repository

Documentation on the use of the GitLab Maven repository and the original ticket .

Interactive Web Terminals for Shell and Kubernetes Runners


CI / CD work is done by Runners, as users configure in the pipeline. But this process cannot be managed, and if the work ends with an error, users will not be able to sort out the details and determine the intended source of the problem. Interactive web terminals allow you to connect to work in progress or complete and manually run commands, helping you better understand what is happening in the system.

Interactive web terminals for Shell and Kubernetes Runners

Documentation for interactive web terminals and original ticket .

Improved code reuse in .gitlab-ci.yml


Reusing the CI / CD process code is a great practice that helps make software delivery homogeneous, write and maintain less code for each individual job. We offer a flexible and powerful way to reuse code in YAML templates using a keyword extends.

Improve includes in `.gitlab-ci.yml` for reusing scripts

Documentation for the extends block and the original ticket .

Contributions to private repositories can now be included in the schedule on the user page


We at GitLab love open source software. But sometimes you have to work on a private project that you are not (yet) ready to open to the public. Or you may be limited for privacy reasons. Anyway, GitLab is on your side.

In this release, we present the opportunity to include private contributions to the development in the deposit schedule on your page. If you have enabled this setting for your profile, contributions to private projects will also be displayed in the deposit schedule and in the deposits of the day. Thus, your active work on private projects in GitLab will be accurately represented, without giving out any secret details.

Thanks to George Tsiolis for this feature!

User graph graph

Documentation on private deposits in the profile and the original ticket .

Project page redesign


GitLab constantly keeps its focus on improving the interface of our product.

Together with GitLab 11.3, we update the project's UI pages to better present project information. We made the information on this page more structured, and also aligned the upper section to the left and optimized the indents in the vertical so that you can now quickly view the information about the project and its content.

Redesigned project overview

Project documentation and original ticket .

Protected environments


Operators are often responsible for protecting the environment in which we send the code daily; This task becomes especially important when deploying code in production.

With protected environments, the operator gets full control over which users, groups or accounts have permission to inject code into this environment, which ensures the safety of the environments.

Protected Environments

Documentation on protected environments and the original ticket .

Code Owners


Cod-review is the fundamental practice of any successful project, but it is not always clear who exactly should conduct reviews of changes. Now for each GitLab file, you can assign one or more code owners, indicating the team members responsible for the code in your project.

Code owners are assigned using a file CODEOWNERSin a format similar to gitattributes, and are displayed below the commit details when viewing a file in GitLab.

In the next releases, code owners will also be involved in merge-requisition processes for proposing and approving those who will confirm merger-request. And also in protected branches, only owners of the code will be able to change files .

Code owners

Documentation on the owners of the code and the original ticket .

Predictions for epics with built-in Milestone dates


Before this release, you can set up fixed start and end dates for the epic, which was very useful for high-level epic planning and time tracking. However, since tasks are attached to an epic and assigned to a specific milestone, it would be nice if the epic dates reflected these milestones.

Starting with this release, you can switch between a fixed value of these dates to a dynamic value Из майлстоунов( From milestones). As the planned start, the earliest start date will be chosen among all milestones tied to the tasks of this epic. This period will dynamically change when adding and deleting tasks, adding and deleting milestones to these tasks or changing the dates of the milestones. Similarly, the dynamic completion date of the epic will work.

This feature will be useful for teams that want a smooth transition from long-term “top-down” planning to short-term “bottom-up” planning. More information can be found in the post about Epic road maps that we published a few weeks ago.

Epic forecasting with integrated milestone dates

Documentation on the epic and original ticket .

Other improvements in GitLab 11.3

Notification of the creation of a new epic can be manually connected


In the last release, we added email notifications about new epics for those users who set up group activity notifications on the level Watch. In this release, we add even more features to customize something. Now, using a level, Customyou can turn on or off notifications about this event, as well as about other events.

New epic event as custom notification

Notification documentation and original ticket .

Quick action to add a task to the epic from the task page


From the Epic page, it is quite easy to add to it or delete an already attached task, which is convenient when working on the Epic itself.

But sometimes you work on a task and want to add it to an existing epic, whose name you know. Now it is easy to do this using the quick action on the task page by inserting an Epic URL. In the next release, a quick action will appear to search for an epic by title, with autocompletion .

A quick action will also be added to unpin the task from the attached epic.

Quick action to add issue to epic (from issues)

Quick action documentation and original ticket .

Allowing self-confirmation of Merge Requests


The user who created the merge-request may not be the author of the changes, and other users may add additional changes to the open merge-request. Maintainers can now allow self-approval of Merge Requests in the project settings.

Previously it was assumed that the user who opened the merge-request, by default approves it (including changes made by other people), and therefore he did not participate in the approval of the merge-request. There are many situations where this is not the case, and it will be against other changes. Adding explicit permission removes this assumption.

Documentation on the self-confirmation of merge-requests and the original ticket .

Display of repository languages ​​in the project overview


When viewing projects in GitLab, it is important and useful to immediately see the programming languages ​​used in the repository.

In this release, we add a programming language panel to the project overview showing the relative use of languages ​​in the project.

Display repository languages ​​on project overview

Project documentation and original ticket .

Custom file templates for user instances


Templates for files LICENSE, .gitignore, Dockerfileand .gitlab-ci.ymlallow you to easily add these files to common projects. Own templates for such files can now be added to GitLab user instances by selecting a repository template with them.

Custom templates are useful in cases where GitLab templates are too versatile. For example, if a company requires the use of a user license in each project, or there is a complex Dockerfileone that should be used for each microservice.

Thanks to Daniel Barker for adding custom license templates .

Documentation for templates repositories for the instance and the original ticket .

Web IDE File Templates


File templates for LICENSE, .gitignore, Dockerfileand .gitlab-ci.ymlsimplify the addition of these shared files in a project and can now be used in a Web IDE. File templates in the Web IDE make it easy to launch a new project in the Web IDE and timely update these important files.

File templates in the Web IDE

Web IDE documentation and original ticket .

Added project name field when creating a new project


To add a project name to your newly created GitLab project, you had to go into the project settings and prescribe the appropriate human-readable part of the project address (semantic URL).

With GitLab 11.3, we add a project name field to the “Create a project” form. In addition, the semantic URL is now automatically generated from the name of the project, while it can still be changed manually. This speeds up and simplifies the creation of a new project.

Define project name when creating a new project

Documentation for creating projects and the original ticket .

Store downloaded Wiki files in the Wiki repository


Images uploaded to the wiki via the wiki editor are now stored in the Git repository. These images will be displayed in a local preview using Gollum .

Previously, the images were saved in the project downloads directory, in the same place as the other attachments that are loaded in tickets and merge-requests. This led to the impossibility of an adequate local viewing of the wiki, as well as the impossibility of transferring to another Git repository.

Wiki documentation and original ticket .

SAST support for Groovy


Static Application Security Testing (SAST) is designed to detect vulnerabilities in the source code as soon as this code enters the repository. To do this, the code looks for known patterns and common errors that may lead to security problems in the application. That is why each language needs special support.

With GitLab 11.3, we add Groovy to the list of languages ​​supported by GitLab SAST. Projects using this language are now detected automatically, so to enable this feature, you do not need to change anything in the code or in the pipeline definitions. Auto DevOps also supports it as part of its default configuration.

SAST documentation and original ticket .

Filter for web-based push events


Web hooks for push events make it easy to automatically notify external services about new commits. However, branches usually have different importance. Push events can now be filtered by branches, so external services will be notified only of changes that are important to you.

Previously, web hooks were not filtered by GitLab, and most external systems are not able to filter incoming events. This meant that it was impossible to integrate these external services directly with GitLab if you wanted only a subset of the push events to be used by the external service.

Thanks to Duana Saskia for this feature!

Filter webhook push events by branch

Web hooks documentation and original ticket .

Notifications for Library Metrics


In GitLab 11.2, the ability to set alerts for custom metrics was added , which allowed developers to receive notifications in case of any problems with their applications.

In GitLab 11.3, we have extended alert support for all metrics, including default metrics provided with our library metrics .

Alerts for library metrics

Alert documentation for metrics and original ticket .

Auto DevOps is enabled by default.


Auto DevOps has become publicly available in GitLab 11.0, and although it has gained widespread acceptance, we want all GitLab users to take advantage of its capabilities. Auto DevOps already out of the box provides significant benefits, from auto build (Auto Build) to auto monitoring (Auto Monitoring).

Starting with GitLab 11.3, Auto DevOps will be enabled by default on both and user instances so that every project can take advantage of these features.

Check the Auto DevOps on / off documentation if you want to disable it for your project or for the entire instance.

Auto DevOps enabled by default

Auto DevOps documentation and original ticket .

GitLab Geo Improvements


We are constantly focused on improving Geo , our feature for geographically distributed teams. Some of the major improvements in GitLab 11.3 are:

You can also read about how we created GitLab Geo .

Documentation Geo configuration and board problems by Geo .

Automatic shutdown of Auto DevOps for the project at the first failure of the conveyor


At GitLab, one of the key product values ​​is “enabled by default” . When we introduce a new customizable feature, which we think is very important, we enable it by default so that everyone can benefit from it. Although Auto DevOps supports projects that use the most popular programming languages, there may be specialized projects that require additional configuration.

Since we want to be sure that we are not launching Auto DevOps pipelines for projects that are not supported, we will disable Auto DevOps if one of the pipelines fails. GitLab will notify the project owner of this, so that if desired, he can make the necessary configuration changes to continue working with Auto DevOps. Project owners can re-enable Auto DevOps after making the necessary changes.

Automatically disable Auto DevOps for project upon first pipeline failure

Documentation on the inclusion of Auto DevOps and the original ticket .

Gitaly v1.0


Access to Git for regular use of GitLab can now be completely through Gitaly, the GitLab gRPC service for accessing Git. This means that you can run Gitaly on your server without NFS, when all additional features are enabled.

In the next release of Gitaly v1.1, all features will be enabled by default. All remaining features will use Gitaly, so you can do without NFS.

Read in our blog about the path to Gitaly v1.0 .

Documentation on Gitaly and original epic .

GitLab Runner 11.3


We are also releasing GitLab Runner 11.3 in this release. GitLab Runner is an open source project that is used to run your CI / CD work and send the results back to GitLab.

The most important changes are:

A list of all the changes can be found in the CHANGELOG GitLab Runner.

GitLab Runner Documentation

The list of open source software components used by GitLab is now available online.


Starting from GitLab 11.3, we are making the list of open source software used by GitLab more accessible. Prior to this release, it was available in each of our Linux packages, which required downloading and extracting content.

Now we immediately post this information online so that it can be easier to find as well as link to it. The list is available for GitLab CE and GitLab EE .

Detailed release notes and upgrade / installation instructions can be found in the original English post: GitLab 11.3 released with Maven Repository and Protected Environments .

Cattidourden , ainoneko , rishavant and nick_volynkin worked on translation from English .

Also popular now: