GitLab 11.3 Released with Maven and Secure environments Repository

GitLab 11.3 supports Maven, Code owners, Secure environments, and Epic forecasting repositories. These features help automate environment and code management, while providing additional efficiency for Java developers.

Maven repository

We have expanded support for Java projects and developers by creating Maven repositories directly in GitLab. This provides Java developers with a secure, standardized way of sharing version control in Maven libraries and the opportunity to save time by reusing these libraries for different projects. This feature is available in GitLab Premium.

Code owners and Secure environments

GitLab Core now supports assigning code owners to files to indicate the appropriate team members responsible for the code. This feature prepares us for future releases in which internal code-level controls will be applied.
Operators available in GitLab Premium can also use secure environments to set permissions that determine who can deploy code in production environments. This greatly reduces the risk that the wrong person will do what he shouldn’t do and will increase the overall safety of the environment.

Epic forecasting

A new portfolio management feature in GitLab Ultimate can automatically predict the start and end dates of epic , based on the target dates of its releases. With this improvement, portfolio managers will be able to compare their planned start and end dates with work that is scheduled through checkpoints to get an idea of ​​possible failures in the epic schedule. This will allow faster and better decisions on what can be done and when it is necessary to adjust the plans.

Everyone can contribute

Many of these improvements are a contribution from the huge GitLab community. We look forward to your feedback and suggestions on these great new features. Together - we are force!
Let us know what you think in the comments below. What do you expect from this release? What else can we improve?

Main features released in GitLab 11.3

Maven repository

(available in version: Premium, Ultimate, Silver, Gold)

It is important for any developer organization to have a simple and secure way to manage dependencies. Package management tools, such as Maven for Java developers, provide a standardized way to share and control the versions of these libraries in different projects.

In GitLab 11.3, we proudly offer Maven repositories built directly into GitLab. Lower-level service developers can now publish packaged libraries to their project’s Maven repository. They can then share a simple XML fragment with other teams that want to use this library, and Maven and GitLab do the rest.

Here is an example of a project that builds and synchronizes data from a local repository up to the GitLab Maven repository. It's simple!

Interactive Web Terminals for Shell and Kubernetes Runners

(available in all versions)

Joby CI / CD run by runners based on the configuration provided by users in the definition of their pipeline. However, the launch is not interactive, and if it fails, users cannot go into details to determine the possible source of the problem. Interactive web terminals allow you to connect to a running or completed job and manually run commands to better understand what is happening in the system.

Improve includes in .gitlab-ci.yml to reuse scripts

(available in versions: Starter, Premium, Ultimate, Bronze, Silver, Gold)

The reuse of the CI / CD process code is a great practice that helps to ensure the consistency of the software and minimizes the number of scripts per job needed for writing and support. We now offer a flexible and efficient approach to reuse code in templates using the YAML extends keywords.

Include private add-ons in user add-on graph

(available in all versions)

At GitLab, we love open source! But it happens that you are working on a private project, which - for now - do not want to share, or are limited by a confidentiality agreement. In any case, GitLab will cover you.

In this issue, we offer the option of including private add-ons in the add-on graph of your profile. Add-ons to private projects are now displayed in the add-ons and add-ons of the current day if you enable this option for your profile. Thus, active work on private projects of GitLab is displayed delicately, without disclosing any secret details.

Thank you, George Tsiolis , for your contribution!

Overview of the updated project

(available in all versions)

Iteration on our user interface is where we constantly strive for the best.

In GitLab 11.3, we update the user interface of the project overview page to make it easier for you to study the project. By improving the overall information structure of this page, we align the top section of the header with the left edge and optimize the vertical spacing so that you can view the project and its contents more quickly.

Secure environments

(available in versions: Premium, Ultimate, Silver, Gold)

Operators often have a delicate task of protecting the environment in which we embed code every day. The task becomes especially important when deploying code in a production environment.

With a secure environment, operators get full control over which person, group or account is allowed to inject code into a specific environment. This gives additional protection and security.

Code owners

(available in versions: Starter, Premium, Ultimate, Bronze, Silver, Gold)

Review of the code is necessary in every successful project, but who is watching the changes is not always clear. GitLab now supports pinning code owners for files, indicating the team members responsible for the code in your project.

Code owners are assigned using the CODEOWNERS file, a format similar to [gitattributes] (https://git-scm.com/docs/gitattributes) , and are listed below for details about the commit. They can be seen when viewing a file in GitLab.

In future releases, code owners will be integrated into the merge program request workflow to suggest approvers , appoint approvers and ensure that code owners are executed .

Epic prediction with integrated key dates

(available in versions: Ultimate, Gold)

Prior to this release, you could set fixed values ​​for the planned start date and the planned end date of the epic. This is useful for high-level planning and epic tracking. However, since epic themes are attached to the epic, and the themes have real deadlines, it would be helpful if the epic dates reflect these dates.
With this version you can easily switch from a fixed value for any of the dates to a dynamic value called From milestones . For the planned start date of this dynamic value, the earliest start date of all stages related to epic topics will be used. It is truly dynamic, as it will change, if topics are added or removed, if target dates are set or canceled (for these topics) or if the start dates of these stages are changed. The dynamic version of the planned epic end date is similar.

A useful feature if you want to smoothly transition from high-level downstream analysis to micro-level upstream analysis. See more in the epic schedule post published a few weeks ago.

Other improvements in GitLab 11.3

Setting up epic event notifications

(available in versions: Ultimate, Gold)

In the previous version of the new epic, we emailed those users who set up group notifications on Watch . In this release, we add more custom settings. Now you can configure this event trigger to turn on / off using a custom Custom alert level along with other triggers.

Quickly add a theme to an epic (from themes)

(available in versions: Ultimate, Gold)

Adding a theme to an epic (or deleting an already attached one) is easily done directly from an epic page. This is useful when you are already working in epic.

But it happens that you work in the subject, knowing that you need to attach it to an existing well-known epic. Now you can do this with a simple quick action on the theme page by inserting the epic URL. In the future version, you can even perform an epic search through the quick action command using auto-complete .

In addition, another quick action with the theme will allow you to remove it from the epic already attached.

Allow self-validation of merge requests

(available in versions: Starter, Premium, Ultimate, Bronze, Silver, Gold)

The user does not have to be a change author to create a merge request, and when it is open, other users can add additional changes to the request. Now owners can allow independent approval of merge requests from project settings.

Previously it was assumed that the user who opened the merge request implicitly approved the merge request and was therefore excluded from the approval of the merge request. There are many situations where this is not the case. Permission to self-approval eliminates this assumption.

Display of repository languages ​​in the project overview

(available in versions: Core, Starter, Premium, Ultimate, Free, Bronze, Silver, Gold)

The code languages ​​that make up the repository are relevant information when learning about GitLab projects.

In this release, we add a code language panel to the project overview, showing all the relevant languages ​​that make up the repository, including their relative number.

Custom file templates for self-managed instances

(available in versions: Premium, Ultimate)

The templates for the LICENSE , .gitignore , Dockerfile and .gitlab-ci.yml files .gitlab-ci.yml easy to add these shared files to projects. Custom file templates can now be added to self-managed GitLab instances by selecting a generic template repository containing your templates.

Custom templates are useful when the templates provided by GitLab are too universal, such as a user license that should be used for each project in a company, or a complex Dockerfile file that should be used for each microservice.

Thanks to Daniel Barker for adding custom license templates .

File Templates in the Web IDE (Web Integrated Development Environment)

(available in all versions)

File templates for LICENSE , .gitignore , Dockerfile and .gitlab-ci.yml make it easy to add these shared files to a project, and now you can use them in the Web IDE. File templates in the Web IDE make it easy to create a new project in the Web IDE, and also help keep these important files up to date.

Setting the project name when creating a new project

(available in all versions)

To add a project name to a newly created GitLab project, you had to go to the project settings and rewrite the project name in a format that can be processed in the URL format.

In GitLab version 11.3, we added the field “Project Name” to the “Create Project” form. In addition, the project name in the URL-compatible format in the new version is automatically generated from the project name, while the ability to edit this field is saved. This improvement speeds up and simplifies the process of creating a new project.

Storing Wiki Downloads in Wiki Repositories

(available in all versions)

Images uploaded to the wiki via the wiki editor are now stored in the Git repository. This means that the images will be displayed in a local preview of Wiki pages using Gollum .
In previous versions, images were stored in the project downloads directory, and attachments were loaded into problem messages and merge requests. This prevented a local preview of the Wiki pages or their transition to another Git repository.

SAST support for Groovy

(available in versions: Ultimate, Gold)

Static application security testing (SAST) is responsible for finding vulnerabilities in your source code immediately after it is placed in the repository, identifying known patterns and common errors that can cause a security breach in a ready-made application. It is for this reason that individual support is needed for each individual language.

In GitLab 11.3, we present Groovy in the list of languages ​​supported by the SAST system from GitLab. The new version automatically detects projects using this language, and you do not need to make any changes to your code or pipeline to enable this feature. Auto DevOps (automatic integration of development and operation) also supports this feature as part of its standard configuration.

Filtering push notifications webhukov on branches

(available in all versions)

Web push notifications for push notifications make it easy to automatically notify external services about new transaction commits, but different branches often have different meanings. Push notifications in the new version can be filtered by branches so that external services receive notifications only about changes that matter to you.

Previously, GitLab didn’t have a filtering function for webchukas, and most external systems do not have the function to filter incoming notifications. This means that previously it was not possible to integrate these services directly with GitLab, if you had to ensure that only a certain subset of push notifications are used by external services.
Thanks for adding Duan Saskia for this!

Notifications for library metrics

(available in versions: Ultimate, Gold)

In GitLab 11.2, we added the ability to set alerts for individual metrics , 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 metrics that are provided by default with our library metrics .

Auto DevOps is enabled by default.

(available in all versions)

Auto DevOps was made available for public access in GitLab version 11.0 and, although it was a significant improvement, we would like to give all GitLab users the opportunity to use these great features. Auto DevOps provides important benefits directly in the “boxed” version, from Auto Build to Auto Monitoring.
Starting with GitLab 11.3, Auto DevOps will be enabled by default both on GitLab.com and on performing copies of the program under independent management, so that for each project you can use these functions.

Please read the documentation on auto on / off Auto DevOps if you want to disable these functions for your project in the entire copy of the program.

Geo Feature Enhancement

(available in versions: Premium, Ultimate)

We continuously focus on improving the Geo function for distributed workgroups. Some notable improvements in GitLab 11.3 include:

• git fetch and git push git fetch on the secondary Geo nodes in the new version are automatically redirected to the primary node when using SSH
• Disabled WiKi-pages of the project are now synchronized correctly.
• The change in the checksum on the Geo Admin Area page (administration page) currently reflects the correct percentage
• Updates as a result of merge requests and branches are now generated correctly.
  You can also see how we build GitLab Geo .

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

(available in all versions)

GitLab considers one of the core values ​​of a product to be “on by default” . When we introduce a new feature with configuration capability, which we consider to be a great value, we set it to ON by default, so that everyone can take advantage of it. Although Auto DevOps supports projects that use the most popular programming languages, some specialized projects may require additional configuration.

Since we want to ensure that we don’t run Auto DevOps pipelines for projects that we don’t support, we disable Auto DevOps automatically if any of its pipelines fail. GitLab will definitely inform the project owner of such a shutdown so that he, if he wishes to work with Auto DevOps, can make the necessary configuration changes. After making the necessary changes, project owners can start Auto DevOps again.

Gitaly v1.0

(available in all versions)

Access for regular use of GitLab can now be fully implemented through Gitaly, a gRPC service (open source remote call system) for accessing Git. This means that Gitaly can be launched on its own server without NFS (network file system) when all functions are selected by choice (by selecting the appropriate checkboxes).

In the upcoming major version of Gitaly v1.1, all checkboxes for the corresponding functions will be selected by default, and the last few remaining functions will use Gitaly, thereby eliminating the need for NFS.
See the post in our blog about the development of Gitaly v1.0 .

GitLab Runner 11.3

(available in all versions)

Also today we are releasing a version of GitLab Runner 11.3! GitLab Runner is an open source project that is used to perform CI / CD tasks and send the results back to GitLab.

Below are the most interesting changes:

• Added initial support for the CI web terminal.
• Introduced GCS adapter (Global Cache Service, resource caching service) for remote cache
• Docker images alpine:3.8
• Configuring helper image has become more flexible
• Content-Range for PATCH /api/v4/jobs/:id/trace request PATCH /api/v4/jobs/:id/trace
• Fixed problem of HTTPS validation when using the ssh control program

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

A list of all open source software components used by GitLab is available.

(available in all versions)

Starting with GitLab 11.3, we have simplified access to the list of all open source software components used by GitLab. Previously, it was available in each of our packages for Linux, but in order to get it, it was necessary to download and unpack the contents.
We have now published this information online, so now it’s easier to access it and link to it. This list is available for GitLab CE and GitLab EE .

General improvements

(available in versions: Core, Starter, Premium, Ultimate)

• Version GitLab 11.3 includes the Mattermost 5.2 , an open source alternative to Slack , which provides an updated plugin system, the ability to search through archived channels, support for the Romanian language, and much more. Since this version includes security updates , it is recommended to install it.
• gitlab-elasticsearch-indexer been updated to version 0.2.2.
• omnibus-ctl been updated to version 0.6.0.
• The Redis tcp_backlog and HZ settings , as well as the max_concurrency in sidekiq_cluster, are now configurable.
• The maximum amount of memory that Sidekiq can use by default is 2GB.
• SSL compression was disabled by default for gitlab-psql and gitlab-geo-psql .

Performance improvement

(available in all versions)

Some notable improvements in GitLab 11.3 include:

• Acceleration of the first load of a newly created merge request by allocating and caching background differences during its creation
• Accelerating the loading of the “Last Commit” column in the file structure by rendering to Markdown during bulk loading of commit headers

Termination of support

Docker version support in GitLab Runner

In the version of GitLab 11.4 (which will be released on October 22, 2018), in accordance with the latest Docker recommendations , it is not recommended to use versions before 1.12 (API version 1.24). After version 11.4, these old versions will no longer be supported officially and may stop working at any time.
Date of deletion: October 22, 2018

Update indicator

Upgrading to GitLab 11.3 from the latest version 11.2 does not require downtime. To upgrade without downtime, please see the “Upgrade without downtime” documentation .
In this version, there are migrations of files and data, as well as migrations after the deployment of the new version, and to help with large migrations, we have introduced background migrations.
Migrations to GitLab.com take about nine minutes, and migrations after deploying a new version take a total of about 15 minutes. On the other hand, the background transition to new versions is the Sidekiq tasks (open source workplace scheduler) performed synchronously. According to our expectations, the transition on GitLab.com should take approximately 90 days for this version. .
GitLab Geo Geo .

, :

• GitLab Community Edition ( )
• GitLab Enterprise Edition ( )
• GitLab Runner

Installation

GitLab, GitLab .

Update

.

GitLab

GitLab SaaS ( , , ).
: .

• Core : , GitLab .
• Starter : , .
• Premium : , , .
• Ultimate : , , .
  SaaS – GitLab.com : , .
• Free : . Free , Gold .
• Bronze : , .
• Silver : , , .
• Gold : CI/CD. Gold .