GitLab 11.10 released with Pipelines on the Operations Dashboard, Pipelines for Merged Results, and Multi-line Merge Request Suggestions

GitLab 11.10 released with Pipelines on the Operations Dashboard, Pipelines for Merged Results, Multi-line Merge Request Suggestions, and much more!

Easily see pipeline health across projects

GitLab continues to add features to provide visibility into the DevOps lifecycle. This release enhances the Operations Dashboard with a powerful feature that provides an overview of pipeline status.

This is handy even when looking at a single project's pipeline, but is especially valuable when using multi-project pipelines - common when you have a microservices architecture and you need to run a pipeline to test and deploy code housed in multiple different project repositories. Now you can get instant visibility at a glance into the health of all of your pipelines on the Operations Dashboard, no matter where they run.

Run pipelines against merged results

Over time it’s possible for your source and target branches to diverge, which can result in the scenario where both source and target pipelines pass, but the combined output fails. Now, you can run pipelines against the merged result prior to merging. This allows you to quickly catch errors that would only surface if you had rebased often, allowing for much quicker resolution of pipeline failures and more efficient usage of GitLab Runners.

Further streamline collaboration

With GitLab 11.10, we provide even more features to simplify collaboration and developer workflows. In a previous release, we introduced merge request suggestions, allowing a reviewer to suggest a one-line change in a merge request comment that can be readily committed from within the comment thread interface. Our users loved it and wanted more. Now, you can suggest a multi-line change, specifying which existing lines to remove, and introducing multiple lines of additions. Thank you for contributing improvement suggestions!

Key features released in GitLab 11.10

Pipelines on the Operations Dashboard

The Operations Dashboard in GitLab is a powerful feature allowing users to have an overview of project information throughout the entire GitLab instance. You add individual projects, one by one, so it’s flexible to whichever specific projects are of interest.

With this release, we added pipeline status information to the Operations Dashboard. This helps teams view the pipeline health of all the projects that they care about, together in a single interface.

Pipelines for Merged Results

When working in a feature (source) branch, it’s normal to have it diverge over time from the target branch if you aren’t rebasing frequently. This can result in a situation where both the source and target branch’s pipelines are green and there are no merge conflicts, but the combined output will result in a failed pipeline due to an incompatibility between the changes.

By having your merge request pipeline automatically create a new ref that contains the combined merge result of the source and target branch, then running the pipeline against that ref, we can better ensure that the combined result will be valid.

Please note that if you are using merge request pipelines (in any capacity) and you use private GitLab runners that are version 11.8 or older, you will need to upgrade them to avoid running into the issue described in gitlab-ee#11122. Users of GitLab’s shared Runner fleet are not impacted.

Suggest changes to multiple lines

Collaborating on merge requests often involves spotting problems and suggesting a solution. In GitLab 11.6, we introduced support for suggesting a change to a single line.

With 11.10, changes can now be suggested to multiple lines when leaving a comment on a merge request diff, and accepted with a single click, by any user with write permissions to the source branch. This new feature avoids the copy/paste workflow of old.

Scoped Labels

Scoped Labels enable teams to apply mutually exclusive labels (that share the same scope) on an issue, merge request, or epic, solving the use cases of custom fields and custom workflow states. They are configured simply using a special double colon syntax in the label title.

Suppose you wanted a custom field in issues to track the platform operating system that your features target. And each issue should only target one platform. You would create labels platform::iOS, platform::Android, platform::Linux, and others, as necessary. Applying any one of these labels on a given issue would automatically remove any other existing label that starts with platform::, as desired.

Suppose you have the labels workflow::development, workflow::review, and workflow::deployed, representing workflow states of your particular team. If an issue already has the label workflow::development applied, and a developer wanted to advance the issue to workflow::review, they would simply apply that label, and the workflow::development label would automatically be removed, as desired. This behavior already exists when you move issues across label lists in an issue board representing your team’s workflow. But now team members who may not be working in an issue board directly, would still nonetheless be able to advance workflow states consistently in issues themselves.

More thorough Container Registry cleanup

In normal use of the Container Registry with CI pipelines, typically you will end up pushing many iterative revisions to the same tag. Due to the way Docker Distribution is implemented, the default behavior is to preserve all revisions in the system – this ends up consuming a lot of space under this usage pattern. By using the -m parameter with registry-garbage-collect, administrators now have an easy way to wipe out these historical revisions and free up valuable storage space.

Purchase add-on CI Runner minutes

Users on GitLab.com’s paid plans (Gold, Silver, Bronze) can now purchase additional CI Runner minutes. Previously, users were limited by the minutes quota included in their plan. This improvement enables users to proactively purchase minutes in addition to their free minutes, which reduces the potential for any interruptions in service due to stopped pipelines.

The current price is $8 for 1,000 minutes and there is no cap to how many add-on minutes you can buy. Your add-on minutes will only begin to be used once your monthly quota has been used and whatever add-on minutes are left at the end of the month will roll over. In a future release, we aim to extend this to Free plans as well.

Composable Auto DevOps

Auto DevOps enables teams to adopt modern DevOps practices with little to no effort. Starting in GitLab 11.10 each job of Auto DevOps is being made available as an independent template. Using the includes feature of GitLab CI, users can include only certain stages of Auto DevOps while continuing to use their own custom gitlab-ci.yml. This will enable teams to include just the desired jobs while taking advantage of any updates made upstream.

Automatically manage group members on GitLab.com using SCIM

Until now, managing group membership on GitLab.com was a manual effort. You’re now able to use SAML SSO and manage group membership with SCIM, allowing your organization to create, remove, and update users on GitLab.com.

This is especially useful for enterprises who typically manage large numbers of users with centralized identity providers. Now, you’re able to use a provider like Azure Active Directory as the single source of truth – and feel confident that your users will be provisioned and de-provisioned automatically based on your identity provider, not by hand.

Sign in to GitLab.com with your own SAML provider

Previously, SAML-based SSO for groups required that a user sign in with both their GitLab user credentials and their identity provider. Now, a user will be able to use SSO to immediately sign in with a GitLab user linked to the configured group.

This removes the need to sign in twice, making SAML SSO more convenient and useful for enterprises using it on GitLab.com.

Other improvements in GitLab 11.10

Child Epics roadmap

In a previous release, we added Child Epics – the ability to have epics of epics – to help teams manage work breakdown structures. Child epics are shown in the epic page of the parent epic.

With this release, you can now see a roadmap view of the child epics in the parent epic page itself. This helps teams see the timeline view of those child epics, allowing you to manage time dependencies.

Merge request popovers

In this release, we introduce enriched popovers when hovering over a merge request link. While we previously only displayed the title of the merge request, you can now view the merge request status, CI pipeline status, title, and short URL.

Filter merge requests by target branch

Git workflows for releasing or deploying software often involve multiple long-running branches, either for backporting fixes to older versions (e.g. stable-11-9) or moving through a QA process to product (e.g. integration), but finding the merge requests that target these branches can be difficult among many open merge requests.

The merge request list for projects and groups can now be filtered by the target branch of the merge request, making it simpler to find the merge request you are looking for.

Push and merge when pipeline succeeds

Trunk-based development claims that long-running branches should be avoided in favor of small, short-lived, single-owner branches. For the smallest changes it is not uncommon to push directly to the target branch, but this runs the risk of breaking the build.

In this release, GitLab supports new Git push options to open a merge request automatically, set the target branch, and enable merge when the pipeline succeeds via the command line, at the moment that you push to your branch.

Sort Wiki pages by created date

A project’s Wiki allows teams to share documentation and other important information conveniently, side by side with source code and issues. In this release, the list of pages in a Wiki can be sorted by created date and title, allowing users to locate recently created content quickly.

Improved integration with external monitoring dashboards

GitLab can access multiple Prometheus servers (at the environment, project and soon group levels) but the complexity of multiple endpoints can be difficult or unsupported by common dashboarding tools. In this release teams can now interact with a single Prometheus API interface, making integration with services like Grafana much simpler.

Monitor resources requested by your cluster

GitLab can assist you by monitoring the Kubernetes cluster you use for your staging and production applications. Starting in this release, you can monitor the requested CPU and Memory resources by your cluster helping you spot potential application impacts before they happen.

Multiple queries per chart

GitLab allows you to create charts to visualize the metrics you are collecting. Often, such as when you want to see the maximum and average value of a metric, it’s crucial to be able to visualize multiple values on the same chart. Starting with this release, you can now do so.

SAST for Elixir

We are continuing to add support for more languages and depth in our security scans. With this release, we enable security scanning for projects created using Elixir, now broadened to projects created using the Phoenix framework.

Multi-module Maven projects support for Dependency Scanning

This release enables multi-module Maven projects for GitLab Dependency Scanning. Previously, if a sub-module had a dependency with another sub-module sibling, it could not resolve the download from the Maven Central repository. Now a multi-module Maven project is created with two modules and a dependency between the two modules. The sibling dependency is now available in the local Maven repo, permitting the build to continue.

Add metrics report type to merge requests

GitLab already provides several report types to be included directly into the merge request – from Code Quality and Unit Test reports from the Verify stage to SAST and DAST from the Secure stage.

While those specific report types are very valuable, there is also value in providing a primitive that can be used across many different types of use cases. In GitLab 11.10 we are shipping metrics reporting directly in the merge request that expects a simple key/value pair of metrics. This will allow users to track any changes, including custom metrics, over time and how they change with a given merge request. Use cases such as memory usage, specialized load testing, and other code health statuses can be converted to simple metrics that will then be exposed directly in the MR alongside the other built-in reports.

Allow users to change the path for cloning in CI

By default, the GitLab Runner clones the project to a unique subpath of the $CI_BUILDS_DIR. However, for some projects, such as Golang projects, there may be a requirement to have the code cloned to a specific directory to be built.

In GitLab 11.10, we’ve introduced a variable called GIT_CLONE_PATH that allows users to specify the specific path that the GitLab Runner will clone to before starting the job.

Simple masking of protected variables in logs

GitLab provides several ways to protect and limit the scope of variables in GitLab CI/CD. However, there are still ways that variables can leak into build logs, either intentionally or unintentionally.

GitLab takes risk management and audit seriously and continues to add features to help with compliance efforts. In GitLab 11.10, we’ve added the ability to mask certain types of variables if they are found in the job trace logs, adding a level of protection against accidentally leaking the content of those variables into the logs. Also, GitLab will now automatically mask many of the built-in token variables.

Update Kubernetes deployments label selector

Deploy boards provide an easy way to gain insight into your Kubernetes deployments.

As part of this release, we’re updating the way labels are matched to deployments; deploy boards will now match by app.example.com/app and app.example.com/env or app. This will allow us to prevent conflicts when doing filtering and risk incorrect deploys associated to the project.

Just-in-time Kubernetes resource creation

GitLab’s Kubernetes integration takes advantage of RBAC security by creating a service account and a dedicated namespace for each GitLab project. Starting with this release, to maximize the efficiency with which these resources are created, they will be created only when they are needed for deployment.

When a Kubernetes deployment takes place, GitLab CI will create the resources prior to deployment.

Show function invocation count for Knative functions

Functions deployed with GitLab Serverless will now include the number of invocations received for the particular function. Showing the number of invocations requires Prometheus to be installed on the cluster where Knative is installed.

Add control for git clean flags for GitLab CI/CD jobs

By default, GitLab Runner runs a git clean as part of the process of checking out your code while running a job in GitLab CI/CD. In GitLab 11.10, we’re adding the ability for users to control the flags passed to the git clean command. This will help teams who have dedicated runners or are building projects from large mono repositories to manage the checkout process prior to executing their scripts. The new variable GIT_CLEAN_FLAGS defaults to -ffdx and accepts all the possible options of the git clean command.

Allow Developers to create projects in groups in Core

We added a configurable option to allow the Developer role to create projects in groups back in 10.5, and we’re adding this option to Core. Creating projects is a key capability for productivity in GitLab, and moving this option to Core helps reduce barriers when members of an instance want to work on something new.

External Authorization in Core

Secure environments may require checking with an additional external authorization resource to permit project access. We added support for this additional layer of access control in 10.6, and we’ve heard requests from the community to move this functionality to Core. We’re happy to do this for External Authorization and bring this additional level of security to Core instances, since it’s a feature cared about by individual contributors.

Fix returned project_id in blob search API with Elasticsearch

We fixed a bug in the blob search API with Elasticsearch that was incorrectly returning 0 for project_id. You will need to reindex Elasticsearch to get the correct project_id values after installing this version of GitLab.

Merge request popovers

In this release, we introduce enriched popovers when hovering over a merge request link. While we previously only displayed the title of the merge request, you can now view the merge request status, CI pipeline status, title, and short URL.

Push and merge when pipeline succeeds

Trunk-based development claims that long-running branches should be avoided in favor of small, short-lived, single-owner branches. For the smallest changes it is not uncommon to push directly to the target branch, but this runs the risk of breaking the build.

In this release, GitLab supports new Git push options to open a merge request automatically, set the target branch, and enable merge when the pipeline succeeds via the command line, at the moment that you push to your branch.

Improved integration with external monitoring dashboards

GitLab can access multiple Prometheus servers (at the environment, project and soon group levels) but the complexity of multiple endpoints can be difficult or unsupported by common dashboarding tools. In this release teams can now interact with a single Prometheus API interface, making integration with services like Grafana much simpler.

Monitor resources requested by your cluster

GitLab can assist you by monitoring the Kubernetes cluster you use for your staging and production applications. Starting in this release, you can monitor the requested CPU and Memory resources by your cluster helping you spot potential application impacts before they happen.

SAST for Elixir

We are continuing to add support for more languages and depth in our security scans. With this release, we enable security scanning for projects created using Elixir, now broadened to projects created using the Phoenix framework.

Add metrics report type to merge requests

GitLab already provides several report types to be included directly into the merge request – from Code Quality and Unit Test reports from the Verify stage to SAST and DAST from the Secure stage.

While those specific report types are very valuable, there is also value in providing a primitive that can be used across many different types of use cases. In GitLab 11.10 we are shipping metrics reporting directly in the merge request that expects a simple key/value pair of metrics. This will allow users to track any changes, including custom metrics, over time and how they change with a given merge request. Use cases such as memory usage, specialized load testing, and other code health statuses can be converted to simple metrics that will then be exposed directly in the MR alongside the other built-in reports.

Simple masking of protected variables in logs

GitLab provides several ways to protect and limit the scope of variables in GitLab CI/CD. However, there are still ways that variables can leak into build logs, either intentionally or unintentionally.

GitLab takes risk management and audit seriously and continues to add features to help with compliance efforts. In GitLab 11.10, we’ve added the ability to mask certain types of variables if they are found in the job trace logs, adding a level of protection against accidentally leaking the content of those variables into the logs. Also, GitLab will now automatically mask many of the built-in token variables.

Just-in-time Kubernetes resource creation

GitLab’s Kubernetes integration takes advantage of RBAC security by creating a service account and a dedicated namespace for each GitLab project. Starting with this release, to maximize the efficiency with which these resources are created, they will be created only when they are needed for deployment.

When a Kubernetes deployment takes place, GitLab CI will create the resources prior to deployment.

Show function invocation count for Knative functions

Functions deployed with GitLab Serverless will now include the number of invocations received for the particular function. Showing the number of invocations requires Prometheus to be installed on the cluster where Knative is installed.

Allow Developers to create projects in groups in Core

We added a configurable option to allow the Developer role to create projects in groups back in 10.5, and we’re adding this option to Core. Creating projects is a key capability for productivity in GitLab, and moving this option to Core helps reduce barriers when members of an instance want to work on something new.

Fix returned project_id in blob search API with Elasticsearch

We fixed a bug in the blob search API with Elasticsearch that was incorrectly returning 0 for project_id. You will need to reindex Elasticsearch to get the correct project_id values after installing this version of GitLab.

With GitLab 11.6, sudo gitlab-rake gitlab:geo:check checks that Hashed Storage is enabled, and all projects are migrated. See gitlab-ee#8289. If you are using Geo, please run this check and migrate as soon as possible.

In GitLab 11.8, a permanently dismissable warning is displayed on the Admin Area › Geo › Nodes page if the above checks are not resolved: gitlab-ee!8433.

Ubuntu 14.04 support

Canonical has announced that standard support for Ubuntu 14.04 will end on April 2019. We recommend that users upgrade to one of the currently supported LTS versions – Ubuntu 16.04 or Ubuntu 18.04.

Removal date: May 22, 2019

Limit maximum number of pipelines created by a single push

Previously, GitLab would create pipelines for the HEAD of every branch included in a push. That makes sense for developers that may be pushing more than one change at a time (say to a feature branch, and the develop branch).

However, when pushing a large repository with many active branches – perhaps to move, mirror, or fork it from another location - it does not make sense to create a pipeline for every branch. Starting in GitLab 11.10, we will create a maximum of 4 pipelines during a push operation.

Removal date: May 22, 2019

Deprecate legacy code paths GitLab Runner

Since GitLab 11.9, GitLab Runner has been using a new method for cloning/fetching the repository. Currently, GitLab Runner will use the old method if the new one is not supported. Please see this issue for additional details.

In GitLab 11.0 we changed how the metrics server is configured for GitLab Runner. metrics_server will be removed in favor of listen_address in GitLab 12.0. Please see this issue for additional details.

Deprecate entrypoint feature flag for GitLab Runner

In GitLab 12.0, we will switch to the correct behavior as if the feature flag was turned off. Please see this issue for additional details.

Removal date: Jun. 22, 2019

Deprecate support of Linux distribution that reached EOL for GitLab Runner

Some Linux distributions in which you could install GitLab Runner have reached End of Life support.

In GitLab 12.0, GitLab Runner will no longer distribute packages to those Linux distributions. A full list of distributions which are no longer supported can be found in our documentation. Thanks, Javier Jardón for your contribution!

Remove legacy git clean mechanism from GitLab Runner

With GitLab Runner 11.10 we’re introducing a way to configure how git clean command is being executed by Runner. Additionally, the new cleanup strategy removes the usage of git reset and moves the git clean command after the checkout step.

Since this is a behavior change that may affect some users, we’ve prepared a FF_USE_LEGACY_GIT_CLEAN_STRATEGY feature flag. When set to true it will restore the legacy cleanup strategy. More about how to use feature flags in GitLab Runner can be found in the documentation

In GitLab Runner 12.0, GitLab Runner will drop support for the legacy cleanup strategy and remove the ability to restore it with a feature flag. Please see this issue for additional details.

Removal date: Jun. 22, 2019

System Info section in the admin panel

GitLab presents information about your GitLab instance at admin/system_info, but this information can be inaccurate.