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!

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 .

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.

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.

Join us for an upcoming event

This month’s MVP goes to Takuya Noguchi . Takuya made many contributions to GitLab , including fixing bugs, cleaning up both backend and frontend technical debt, as well as making UI improvements. Thank you!

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.

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.

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

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The following improvement has been made to GitLab charts:

The following improvements have been made to Omnibus in GitLab 11.10:

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.

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.

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.

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

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.

To improve the user experience and make handling license keys easier, we’ve redesigned the license page in the admin panel and emphasized the most important elements of the page.

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.

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.

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.

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.

We have added Dynamic Application Security Testing (DAST) results in the Group Security Dashboard to accompany results already present for SAST, Container Scanning, and Dependency Scanning.

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 .

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.

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.

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.

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 future releases, we plan to add additional important information like assignees and milestones and bring popovers to issues too.

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.

We continue to improve the performance of GitLab with every release for GitLab instances of every size. Some of the improvements in GitLab 11.10 are:

List of all changes can be found in GitLab Runner’s CHANGELOG .

We’re also releasing GitLab Runner 11.10 today! GitLab Runner is the open source project that is used to run your CI/CD jobs and send the results back to GitLab.

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.

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.

Group-level clusters now support the installation of GitLab Runner. Group-level Kubernetes runners will appear for child projects as group runners tagged with the labels cluster and kubernetes .

Additionally, starting in GitLab 12.0 we will remove ‘app’ label matching from Kubernetes deployment selector and will instead match only on app.example.com/app and app.example.com/env .

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.

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

Starting with GitLab 11.10 we’ve added the ability to enable/disable Auto DevOps for all the projects that are part of any given group.

Enabling Auto DevOps for your GitLab.com project provides an easy way to get started with modern DevOps workflows, from build all the way to deploy.

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.

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.

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.

This release enriches the Container Scanning report with more metadata, adding impacted component (a Clair feature) to the existing metadata: priority, identifier (with a link on mitre.org), and affected layer (ex: “debian:8”).

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.

Ensuring your GitLab instance stays healthy is critical. We’ve previously given you default dashboards to review in our bundled-in Grafana instance. Starting with this release, we now include additional dashboards to monitor your NGINX load balancers.

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.

Thank you, Hiroyuki Sato , for the contribution!

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.

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.

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.

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.

Deprecations

GitLab Geo will enforce Hashed Storage in GitLab 12.0

GitLab Geo requires Hashed Storage to mitigate race conditions on secondary nodes. This was noted in gitlab-ce#40970.

In GitLab 11.5, we added this requirement to the Geo documentation in gitlab-ee#8053.

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.

In GitLab 12.0, Geo will enforce the Hashed Storage requirement. See gitlab-ee#8690.

Deprecation date: Jun. 22, 2019

Ubuntu 14.04 support

GitLab 11.10 will be the last release with support for Ubuntu 14.04.

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.

Deprecation 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.

Deprecation 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.

In 11.3, GitLab Runner started supporting multiple cache providers; this resulted in new settings for S3 specific configuration. In the documentation, there is a table of what changed, and how to migrate to the new configuration. Please see this issue for additional details.

These paths will no longer be available in GitLab 12.0. As a user, you don’t have to change anything apart from making sure the GitLab instance is running 11.9+ when upgrading to GitLab Runner 12.0.

Deprecation date: Jun. 22, 2019

Deprecate entrypoint feature flag for GitLab Runner

In 11.4 GitLab Runner introduced a feature flag FF_K8S_USE_ENTRYPOINT_OVER_COMMAND in order to fix issues like #2338 & #3536.

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.

Deprecation 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!

Deprecation date: Jun. 22, 2019

Remove legacy GitLab Runner Helper commands

As part of our effort to support a Windows Docker executor, we had to deprecate some old commands that are used for the helper image.

In GitLab 12.0, GitLab Runner will start using the new commands. This only affects users who are overriding the helper image. Please see this issue for additional details.

Deprecation date: Jun. 22, 2019

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.

Deprecation 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.

We’re removing this section of the admin panel in GitLab 12.0 and recommend using other monitoring capabilities.

Deprecation date: Jun. 22, 2019

Support for Prometheus 1.x in Omnibus GitLab

With GitLab 11.4, the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab. Prometheus 2.0 is now included. However, the metrics format is incompatible with 1.0. Existing installations can upgrade to 2.0 and optionally migrate their data using an included tool.

With GitLab 12.0, any installation not yet running Prometheus 2.0 will be automatically upgraded. Metric data from Prometheus 1.0 will not be migrated and will be lost.

Deprecation date: Jun. 22, 2019