GitLab 11.7 is released with Releases, multi-level nested epics and a registry of NPM packages
  • Transfer

Picture to attract attention

Release management has become much easier.

GitLab 11.7 introduces Releases for plans starting at Core. Users will now receive a complete "cast" of the release - the source code with all the artifacts of the project. This eliminates the need to manually collect in one place the source code, the build log, other metadata or artifacts related to this release. This feature will serve as the basis for a more developed and developed release management in the future.

Portfolio management now supports more complex work breakdown structures.

Multi-level nested epics are the most recent addition to Portfolio Management in GitLab, available in Ultimate terms. Nested epics allow you to break work into multi-level structures to create more complex projects and work plans. Epic can now contain tasks and other epics; such a structure would allow a direct link between planning and implementation tasks.

Optimizing JavaScript development with NPM Registry

In terms of Premium, Gitlab 11.7 adds registries of NPM packages directly to GitLab, providing a standard, more secure way to share NPM packages and manage their versions among projects. Just specify the package name and NPM with GitLab will do everything necessary in the same interface.

And even more

It is always difficult to choose which features to include in the brief overview of the monthly release, so we will name a few more cool innovations:

  • Closing a vulnerability using a patch file : GitLab security tools help in the detection of vulnerabilities. With the release of GitLab 11.7, there is an opportunity to cure the vulnerability and offer a solution for projects on Node.js managed by Yarn. So far this is the first official feature covering vulnerabilities, but definitely not the last!

  • Integration with Kubernetes by API : For those who create really many Kubernetes clusters or consider themselves to be a master of work with Kubernetes, we added the API Kubernetes, which will significantly reduce the work manually and simplify life.

  • Viewing interproject pipeline links : Thanks to our new feature - improved interproject pipeline viewing - all the necessary information will now be at your fingertips.

Next you will find a complete list of innovations release GitLab 11.7!

We invite to our meetings

GitLab MVP badge

This month's MVP is MortyChoi

MortyChoi added support for Go private packages in subgroups . Thank you for this contribution, which will help further support this popular language in GitLab!

The main features of the release of GitLab 11.7

Release releases of your projects


Our new feature - Releases - allows you to create releases in GitLab and view them on the overview page. Releases - "cast" the current state of the code, links and other metadata or artifacts related to the release version of the code. Users of your project will now be able to easily access its latest released version.

Publish releases for your projects

Release documentation and original ticket .

Multi-level nested epics


Epic and tasks work together perfectly on the flexibility of long-term work plans, but so far they have been able to create only two-level structures.

In this release, we present nested epics: they can now contain tasks and other epics, which will allow you to create a multi-level work breakdown system. Thus, you will be able to build even more long-term strategic plans or organization goals - to create high-level epics with several levels of epic inside, breaking up the work into parts that are measurable from the point of view of delivery, up to tasks.

Multi-level Child Epics

Documentation on the epic and original ticket .

View interproject pipeline links


Now, in the graph, on the pipeline view page, you can expand incoming and outgoing dependencies in the inter-project pipelines and get an idea of ​​all the pipelines involved - no matter what project they are running or ending.

Cross-project pipeline browsing

Documentation of conveyor schedules and original ticket .

Closing a vulnerability using a patch file


GitLab can detect various types of vulnerabilities in your applications and suggest possible ways to fix them.

Starting with the release of GitLab 11.7, you can download the patch file and apply it to your repository using the command git apply. Then send the changes to the repository, and the security panel will confirm that the vulnerability is closed. This simplifies the process of solving such problems and reduces the time needed to apply the solution. At the moment, dependency scanning reports known vulnerabilities in NodeJS projects running under the package manager yarn, and no extra effort is required. The patch will be displayed in the vulnerability details window when it is available.

Remediate vulnerability with patch file

Documentation on the proposed solutions and the original ticket .

Ability to set application secret keys to variables in Kubernetes


Operators and administrators need to configure key-secrets outside the application repository in order to reduce the risk of disclosing sensitive data. GitLab now offers the ability to configure key-secrets as environment variables that are available to the application in your Kubernetes cluster.

Just start the variable name with K8S_SECRET_, and the corresponding CI pipeline will accept it as the key secret of your Kubernetes application.

Configure Kubernetes app secrets as variables

Documentation on setting up keys-secrets and the original ticket .

Registry NPM-packages


JavaScript developers need a reliable, standardized way to share NPM packages and manage their versions among projects. The package registry for NPM gives this opportunity to developers of low-level services when publishing their code.

In GitLab 11.7, we added the NPM package registry built into GitLab. This means that developers can now use a simple agreement on the name of the packages to use the library in any Node.js project, while NPM and GitLab will do the rest. All this is available through the same interface. This feature will be available in GitLab Premium.

Look at the sample project in which the build and paste into the registry.

NPM registry

Documentation on the registry of NPM packages and the original ticket .

API support for integration with Kubernetes


In this release, we added API support for integration with Kubernetes. This means that all actions that are now available in the GUI β€” adding, deleting and displaying a list of Kubernetes clusters β€” are now also available through the API. This gives development teams the ability to create clusters during development.

API support for Kubernetes integration

API documentation for clusters and original ticket .

Other improvements in GitLab 11.7

Search filter window for navigating task boards


Development teams often use several task boards, which makes it difficult to navigate the drop-down list if there are too many tasks. In this release, we added a search filter to solve this problem. Now you can simply enter a few characters in the search box to quickly reduce the number of tasks to those that are interesting to you, which will greatly simplify navigation.

Search box for issue board navigation

Documentation on the taskbar and the original ticket .

Project List Redesign


Projects are one of the main components of GitLab, so we try to improve the appearance of project lists and simplify working with them.

In GitLab 11.7, we present a new project list user interface design that focuses on readability and provides a brief report on project activity. We have added space for additional project information and empty space to each line in the project list and plan to continue to improve the design with your feedback.

Project list redesign

Project documentation and original ticket .

Support for mailboxes with the catch-all function, including Microsoft Exchange and Google Groups for features that use incoming email


GitLab has several cool features that use incoming email, such as answering email , creating a ticket via email , creating a merge-request (in the Russian localization of GitLab "merge request" by email) and technical support via email . Previously, these features could be used only if your email server supported the sub-addressing feature.

Starting with this release, GitLab supports both sub-addressing and catch-all mailboxes using the new email format, which allows GitLab to integrate with an even greater number of email servers, including Microsoft Exchange and Google Groups, which do not support sub-addressing. .

Documentation for incoming email and original ticket .

Import tasks in CSV format


Often, when development teams start using GitLab, it may turn out that they use different tools and they have inherited data. Perhaps now you are using Jira, but would like to go to task management in GitLab.

Starting with this release, this transition becomes much easier. Since many task tracking systems support exporting CSV files, you can now import such tasks into GitLab, which allows you to continue to work on current tasks, importing the inherited data into GitLab for further searching and retrieval as needed. It will work with Jira or with any other task tracking system that supports CSV export.

Also in GitLab there is already a feature for exporting CSV files .

Import issues CSV

Documentation for importing CSV files and original ticket .

Generating a short SHA sequence as an environment variable


In Git SHA, pointers to specific objects (for example, commits) in the Git repository are composed of 40 characters. Often there is no need to display the entire line, and you want only the first eight SHA characters to be shown for quick reference, although this sequence may not be unique. We have added an environment variable CI_COMMIT_SHORT_SHAfor the CI pipeline to solve this problem, which allows you to generate the first part of the SHA commit.

Short commit SHA available as environment variable

Documentation of environment variables and original ticket .

More stringent restrictions on confirming your Merge Requests


Code review is a practice that should be carried out in any successful project by someone who is not the author of the change. By default, confirmation of your Merge-Requests is prohibited, but this restriction takes into account the authorship of the Merge-Request, and not the commits included in it.

Starting with GitLab 11.7, restrictions on confirming their merge-requests will also prevent confirmation of merge-requests by people who have made changes to them, so merger-requests for authorship of several developers will receive completely independent reviews and confirmations.

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

Authorization support for network includes


When external files are included in your pipeline definition using the keyword, includethese files are requested via HTTP / HTTPS. Now you can access the YAML files in another project without public access (for example, a private project on using the authorization data that the pipeline works with.

YAML documentation includes and original ticket .

Vulnerability Filtering on Group Security Dashboard


The group security panel allows security teams to keep everything under control, revealing vulnerabilities that affect their groups.

With GitLab 11.7, users can filter the displayed vulnerabilities by severity, report type, and project name. Thanks to this, they can focus on what they need and get access to their data faster, which is especially useful when there are a lot of entries in the list.

Filter vulnerabilities in Group Security Dashboard

Documentation on viewing vulnerabilities and the original ticket .

View dependency scan results in group security panel


The group security panel was originally released only with SAST results , so users could not manage other types of vulnerabilities using this feature.

With GitLab 11.7, dependency scan results have been added to the available data set. If you already use the new report syntax , you will automatically see the results in the security panel. The Auto DevOps template has also been updated, and now GitLab Runner version 11.5 or higher is required for it to properly start the dependency scan.

Show Dependency Scanning results in the Group Security Dashboard

Panel security panel documentation and original ticket .

Inclusion of CI / CD files from other projects and templates


The keyword includeallows users to dynamically create CI / CD pipelines with the inclusion of external files in the configuration. Previously, this was only possible for files in the project repository or for remote files uploaded via HTTP.

With GitLab 11.7, users can include their configuration fragments also from other projects and from predefined templates. GitLab will include snippets for specific jobs, such as sastor dependency_scanningso that users can reference them instead of copying and pasting the current definition. Jobs will be automatically updated to the latest version when updating GitLab, so no need to make changes manually.

Include CI / CD files from projects and templates

YAML documentation includes and original ticket .

RBAC default mode when creating Kubernetes cluster


Ensuring the security of the Kubernetes cluster is vital to controlling and restricting user access to the cluster and the actions allowed to these people.

Starting from GitLab 11.7, all clusters will support RBAC by default during creation, providing a more secure and secure infrastructure.

Cluster and RBAC documentation and original ticket .

Support for private Go packages in subgroups


Go packages hosted on GitLab can be installed using the command go get, but this was not previously supported for private projects in subgroups. Starting from GitLab 11.7, any project can be used as a Go package, including private projects in subgroups.

Private packets are supported by a command go getusing a file .netrcand a personal access token in the field password.

Thanks to MortyChoi for this feature!

Subgroup documentation and original ticket .

Support for NGINX Ingress 0.16.0+ metrics


With the release of NGINX Ingress 0.16.0 , Prometheus metrics are now embedded natively , rather than relying on external export tools.

GitLab 11.7 now includes support for metrics exported from NGINX Ingress 0.16.0+, and automatically detects and displays throughput, latency, and deployment error rates.

NGINX Ingress documentation and original ticket .

Skipping CI builds during git push


When users did not want to run the CI / CD pipeline for a certain commit, they could add a special note [ci skip]or [skip ci]to the description of the commit. However, many users do not want or can not change their commit description to add additional information.

Starting from GitLab 11.7, when using Git version 2.10 and higher, users can enable Git push settings to prevent the pipeline from running when they send a commit to GitLab. Now you can use git push -o ci.skipto achieve the same goal without changing the commit description.

Thanks to Jonathon Reinhart for this feature!

Documentation on the omission of CI and original ticket .

GitLab Runner 11.7


We also release GitLab Runner 11.7! GitLab Runner is an open source project used to run CI / CD 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 .

Detailed release notes and upgrade / installation instructions can be found in the original English post: GitLab 11.7 shipped with Releases, Multi-level Child Epics, and NPM Registry .

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

Also popular now: