Release | GitLab
Oct 22, 2019

The latest features available on is currently running the 12.3 release. New features are launched on every week, with a packaged release available on the 22nd of every month. Read on to learn more about the new features available on Note that it may take a few days for a feature to become fully available on, due to deployment schedule and potential feature flags.

Additional information on past releases is available; be sure to check out the 12.3 release for other features we've launched recently. We also have information about upcoming releases if you're interested in seeing what we are doing next.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Tuomo Ala-Vannesluoma

Tuomo’s contribution to GitLab 12.4 enabled private project support for viewing HTML artifacts, a highly requested feature with almost 300 upvotes! This is Tuomo’s second MVP, their first was in GitLab 11.5 where they implemented Access control for Pages. Thank you for your contributions and for engaging with us over the last year - we truly appreciate it!

Key features released in GitLab 12.3

Merge Request Dependencies

Developers often work together to achieve a larger goal through many small changes. These changes need to be merged in a specific sequence to work as intended, but keeping track of these dependencies can be confusing and error prone.

Merge Request Dependencies allow dependencies to be defined in merge requests, to prevent changes from being merged in the wrong order. This also increases the visibility of dependencies during code review to help the reviewer understand the full scope of the proposed changes. This feature was introduced in 12.2 but in 12.4 it has been improved to also support Merge Request Dependencies within the same project.

Merge Request Dependencies

Audit Events API

Audit Events are a powerful way to better understand activity inside GitLab. Organizations may rely on audit events to ensure that user activity adheres to policies; for enterprises operating under regulatory scrutiny, this can be of critical importance.

To make audit events easier to use for automation, we’re introducing an API for instance-level audit events. Using the Audit Events API, administrators can obtain events programmatically and better enable your own powerful alerting and monitoring that meets your organization’s specific needs.

Audit Events API

Code Owner Approvals for Protected Branches

Using merge request approvals to restrict how code is pushed to protected branches is helpful for promoting code quality and implementing compliance controls. However, not all merge requests target stable branches, and not all stable branches need the same controls.

In GitLab 12.4, it is possible to require Code Owner approval for specific branches to prevent directly pushing changes to files or merging changes without a code owner’s approval.

If code owner approval was required using the previous Project setting, this has been applied to your existing Protected Branches.

Code Owner Approvals for Protected Branches

Access Control for Pages is now enabled on

Access Control for Pages allows an authorized administrator to restrict access to a Pages site or make it available to the public. Now, content published by your private projects can require sign in to protect the contents of the published site, making it easier to publish and control access to internal documentation.

Please check out a short video that highlights Access Control for Pages.

Access Control for Pages is now enabled on

Notifications for Releases

You can now subscribe to updates about new releases in a project, so that you will be notified about new versions, even for projects you are not part of. This can be used to stay up to date on new releases from projects that you depend on, without having to check-in manually.

Please check out a short video that highlights Notifications for Releases.

Notifications for Releases

View Pod Logs from Any Environment

Previously, GitLab logs were primarily accessed via the Environments page. This made it difficult to easily switch between logs from different environments for troubleshooting purposes. It also prohibited direct access of logs without first accessing a specific Environment.

Now, with GitLab 12.4, we’ve enabled the ability to view any logs from any environment or pod. From the environments page, you’ll see two buttons to view any pod logs from your Kubernetes clusters. Going forward we’ll continue to improve how you can access your logs including creating a Logging link directly in your Operations menu.

View Pod Logs from Any Environment

Other improvements in GitLab 12.3

Use Jaeger in the GitLab UI

Tracing provides insight into the performance and health of a deployed application by tracking each function or microservice which handles a given request.

Jaeger is an open source, end-to-end distributed tracing system used for monitoring and troubleshooting microservices-based distributed systems.

With GitLab 12.4, users that are using Jaeger can access it and view the performance and health of their deployed application without leaving the GitLab UI.

Use Jaeger in the GitLab UI

Variable Expansion Support for Multi-project Pipelines

When using a multi-project pipeline flow, where one pipeline triggers another, it’s often helpful to be able to store a dynamic value in a variable upstream that you can reference in the downstream pipeline. For example, if a pipeline is running on a branch and you want the $CI_COMMIT_REF_NAME on that branch accessible throughout all of the downstream pipelines.

Previously, the variable didn’t expand so calling a variable downstream via the trigger keyword failed with a no ref name error. Getting this workflow to work required spawning a separate job whose only purpose was to execute a cURL command to kick off the next pipeline passing in the variable state. In addition to requiring extra set up and extra resources to run this workaround loses the ability to visualize the relationship between pipelines in the UI.

Now GitLab will expand variables used inside of the branch property of the trigger keyword, simplifying your pipeline design and adding more flexibility around how your pipelines trigger each other in multi-project scenarios.

DAST for the Master Branch

We are pleased to announce that DAST scans can now run against a project’s default branch inside a dedicated review app. Previously, DAST only ran against feature branches. This enhancement allows the creation of a DAST results baseline on the default branch against which MRs are compared. With this, you can pinpoint the exact branch where new security issues are introduced.

Check for Existence of Files in Pipelines

Adding to the rules: syntax initially introduced in GitLab 12.3, the new rules:exists rule is able to accept an array of paths and will match if any of these paths exist as files in the repository. This is useful in cases where you want to run a CI job only if a certain file exists. For example, only run the tests pipeline when the file tests.yml exists. Use of this rule can help speed up pipelines by skipping stages with no match.

Native Geo Support for Object Storage Replication

In GitLab 12.4, Geo natively supports replicating data in object storage such as LFS objects, job artifacts, and uploads. Previously, Geo could be configured to work with object storage; however, the replication of the content was always left to the object storage provider. This imposed limitations when users relied on local storage appliances that do not support any replication logic.

Native Geo support allows data to be replicated across different object storage providers in different regions (e.g. Amazon in Europe and Microsoft in the United States). Geo users can also use local storage, for example via MinIO, and use Geo to replicate data to secondary nodes.

Native Geo support for object storage replication is currently a beta feature and is not ready yet for production use.

Improved large file handling via Git Partial Clone (alpha)

Storing large binary files in Git has typically been discouraged to prevent the repository growing too large, making cloning and fetching changes very slow. Solutions like Git LFS have provided a workaround by storing large files outside the Git repository, and downloading large files on demand.

In GitLab 12.4, we are adding experimental support for Partial Clone, which allows large files to be excluded when cloning a repository and fetching updates. This removes the need to choose which files should be stored in Git and which files should be stored outside the repository using Git LFS. Partial Clone support is disabled by default, but can be enabled per project, and requires at least Git 2.22.0.

In comparison with Git LFS, instead of requiring large files to be specially handled when authoring the commit, Partial Clone allows developers, CI runners, or any other Git client to specify which files they want to download. This removes the need to teach people which files should go in Git LFS, avoids the problems of trying to rewrite history to migrate large files to Git LFS, and bypasses the frustrations caused by someone accidentally pushing an large file to the Git repository when it should have gone to Git LFS. Simply, large files should just work.

Date Picker for Productivity Analytics

Until now, users were not able to select a specific date range for their metrics in cycle analytics and productivity analytics. This meant that they cannot drill down or report into productivity during a specific sprint or a custom date range since we only provided preset periods such as 7, 30, 60, 90 days. With the release of this feature, users will be able to visualize how their data looks over any time frame and the periods that actually matter to them.

Date Picker for Productivity Analytics

Use VPC Native Setting by Default When Creating GKE Cluster in GitLab

Google Kubernetes Engine provides the ability to create VPC-native clusters, which rely on Alias IPs and provide integrated VPC support for container networking, resulting in a more scalable, secure, and simple system that is suited for demanding enterprise deployments and use cases.

Starting with GitLab 12.4, GitLab’s GKE integration will enable this option by default when creating a GKE cluster.

Restrict Permissions for Manual CI Jobs

Teams often need to create manual jobs to handle things like deployments, soft approvals, or other gates, but in GitLab it’s not obvious how to restrict these permissions to prevent just anyone from completing the action.

This was actually already possible in GitLab today, but wasn’t clearly documented. In this release we’ve significantly improved the documentation for protecting manual jobs to make it more clear how to get this set up.

Delete Designs in Design Management

Sometimes mistakes happen or design goals change and the ability to remove a design from a revision can be important. With deletions in Design Management users can select one or more designs and remove them from the latest version. This enables the latest version of the design to represent the true state of ideas.

Delete Designs in Design Management

Enrich Environment and Deployment API

We have added API functionality that will return the state and last deployment attributes of environments. An example use of that information is to write a script to delete unused environments.

Improved Geo Upgrade Documentation

As part of our effort to simplify the Geo upgrade process, we reworked large parts of the Geo upgrade documentation. GitLab Geo can be deployed in different configurations and depending on the configuration Geo upgrades require different steps. At this moment, upgrading Geo is still highly manual and can involve many individual steps. To improve this in an iterative way, we focused first on improving the Geo upgrade documentation itself. This ensures that the documentation is up-to-date and covers all use cases.

We rewrote the general update steps, archived old update steps, updated zero-downtime upgrade instructions for simple deployments and investigated many other parts of the documentation.

We are also working on instructions for zero-downtime updates of a multi-node, high-availability Geo cluster; however, these instructions require more testing before we release them.

Following this work, we will work on better automation, improved testing, and making certain upgrade procedures more robust.

When viewing a pipeline, it can be helpful to be able to navigate to the merge request(s) associated with that pipeline. We’ve added links directly to the related merge requests to make this simpler and more efficient.

MR links are now shown on Pipeline view

Insert jobs at beginning or end of pipeline via include

A common use case for includes is to add a job at the beginning or end of a pipeline. However, as the author of a shared include, you don’t necessarily know what the first or last stages will be called. This makes it difficult and error prone to try to write a job that runs at the start or end of a pipeline.

In GitLab 12.4, .pre and .post pipeline stages that are guaranteed to run at the beginning or end of a pipeline to make this easier are available.

Upgraded Kubernetes NGINX Ingress Application when Installed via Kubernetes Integration

Keeping your Kubernetes-deployed apps running on the latest version ensures you have the newest features as well as up-to-date security. GitLab 12.4 allows you to use the latest NGINX Ingress application when installing it using GitLab Managed Apps. To upgrade an existing version, uninstall and reinstall the Ingress application using GitLab.

API Endpoint for 'Static Status Check Names' in GitHub Integration

It is now possible to configure the static status check names in the GitHub integration via the API, making it much easier to change this setting on large numbers of projects.

GitLab Runner 12.4

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

Changes include:

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

Admin Override of Artifacts Size per Project/Group

Currently, the artifacts size is set to 100MB by default but some projects need the ability to go over these limits, subject to the discretion of the administrator. To enable this, we’ve added an option in group and project settings to override the global artifacts size limit, similar to how the repository size limit can be customized.

Private Project Support for Online View of HTML Artifacts

Viewing HTML artifacts in a browser window is a key efficiency workflow. Because of how frequently this task is performed, being able to quickly go from browsing your artifacts to opening and reviewing them is important. Without an online view, you need to download the artifact and spin up a webserver locally to view the report. Doing this for every HTML artifact for all of your builds can become an intrusive time-sink that interrupts the flow of work with continual context-switching.

Previously, it was possible to view HTML artifacts in a browser window using GitLab Pages instead of downloading them locally, but this capability was limited to public projects only. This was a problem for many businesses and organizations that use GitLab predominantly with private projects - an online view was simply not available to them. Now thanks to a wonderful community contribution from Tuomo Ala-Vannesluoma, we have added support for online view of HTML artifacts to private projects as well. Note that this requires enabling access control for GitLab Pages to work correctly.

Enable "Cloud Run on GKE" When Creating a Cluster via GKE Integration

When creating a Kubernetes cluster via GitLab’s GKE integration, users can now optionally enable “Cloud Run on GKE” with a single click. GKE will automatically provision the cluster with Knative serving, Istio, and HTTP load balancing. When installed, users can continue to take advantage of the features offered by GitLab Serverless to deploy Knative services with minimal configuration.

Note: Cloud Run for GKE has recently been rebranded as “Cloud Run for Anthos”. We plan to update the name of this feature with Google’s updated branding in next month’s release.

Enable "Cloud Run on GKE" When Creating a Cluster via GKE Integration

Generic Alert Endpoint MVC

People make use of a variety of different tools to monitor their application environments. These tools send critical, time-sensitive alerts when an incident arises and action needs to be taken. Now, GitLab’s Incident Management capabilities include a generic REST endpoint where you can send alerts, regardless of the tool that generated them. When GitLab receives a POST to the endpoint, it will automatically create an incident issue. The payload is included in the issue description and commonly used fields are automatically parsed. This allows you to use GitLab issues as a central place for incident response leveraging inputs from your other tools.

Please check out a short video that highlights the Generic Alert Endpoint MVC.

Generic Alert Endpoint MVC

Geo Supports Using a Single, Location-aware Git URL

Geo now supports providing users with a single remote URL that automatically uses the Geo node closest to them. This means users don’t need to update their Git configuration to take advantage of closer Geo nodes as they move. In fact, end users won’t even have to know that they are using a local Geo node when initially cloning a project. For systems administrators, it removes the need to maintain different Git configurations for users in different locations. This is possible because, Git push requests can be automatically redirected (HTTP) or proxied (SSH) from secondary nodes to the primary node.

Geo can be configured to use different services, such as AWS Route53 or Cloudflare.

Git Activity added to Group IP Address Restriction

GitLab 12.0 saw the introduction of restricting a group’s activity by IP address. In GitLab 12.3, we included API activity in the access restriction. In GitLab 12.4 we’re extending this further to include Git actions via SSH.

The resulting feature now provides extensive coverage, rejecting UI, API, and Git activity if they do not adhere to the group’s IP address restriction. For compliance-minded organizations, especially those on, this provides an comprehensive and important security layer.

Scatterplot for Productivity Analytics

Previously, users were not able to easily visualize and measure velocity over time. In order to enable them to do that, we are adding scatterplots to Productivity Analytics, where users can select ‘Time to Merge’ or any other merge request related metric in order to spot relevant trends or outliers. Users can also zoom in on a particular date range in order to research and analyze specific data sets.

Scatterplot for Productivity Analytics

API for Manually Creating Deployments

We have added API functionality that will allow for creating deployments. This also changes deployments so that the associated CI build is optional. This is needed to lay the foundation to support external environments and deployments to GitLab.

One-click Install for Group Runner on Kubernetes

It’s now easier than ever to create a shared Runner at the group level if you’re using GitLab with Kubernetes. The ability to one-click install a Runner at the project level has been available for a while, but group Runners still needed to be installed manually. Now, you can simply click a button and GitLab will install a shared group Runner for you.

One-click Install for Group Runner on Kubernetes

Design Management System Notes

In GitLab 12.2 we released the first iteration of Design Management, which allowed uploading designs directly to issues. They were uploaded in a separate tab within issues and their activity wasn’t logged, making it harder to identify whether there were designs added the issues. From GitLab 12.4 on, when designs are uploaded, new system notes are output to the issue’s thread to inform the participants. In a future release, we’ll bring status and discussion count indications to the designs to further inform users on design’s activity.

Design Management System Notes

GitHub Integration Default to Static Status Check Names

We have changed the default setting for our GitHub integration to use static status check names by default on new projects. With static status check names enabled on the integration page, your GitLab instance host name is going to be appended to a status check name, whereas in case of dynamic status check names, a branch name is going to be appended. This is a more sensible initial setting that will ensure that requiring status checks works out of the box for users using GitLab CI/CD with a GitHub repository.

Multi-Select & Move Issue Cards

Sometimes, it’s the little things that matter. Whether you’re kicking off your next sprint or you just like to pass the time dragging and dropping on Issue Boards, you’ll be happy to know that you can now multi-select issue cards via Cmd + click on a Mac or Ctrl + click on Windows to move them all at once to a different list.

Sort Packages in the Registry UI

The GitLab Package Registry allows users to build, publish and share npm, Maven and (coming soon) Conan packages. GitLab provides a user interface that displays package metadata and helps users to find their project or group’s packages. However, until recently, users had to manually scroll through their list of packages to find the package they were looking for.

In GitLab 12.4, we are happy to introduce sorting to the Package Registry user interface to improve navigation and discoverability! Now you can sort packages at the project and group level by created date, name, version, and type. In the coming milestones, we are working on adding last commit and branch and will be redesigning the user interface to include all relevant metadata.

Sort Packages in the Registry UI

Global View for Instance-level Cluster Deployments/Environments

The Environments view was introduced in GitLab 12.3 for group-level clusters. The Environments section of the cluster page provides an overview of all the projects that are making use of the Kubernetes cluster, including the deployments/environments that have been provisioned and the number of pods used by each environment. Now in 12.4 the “Environments” view is available for instance-level clusters. Navigate to your instance Kubernetes page and click on the Environments tab. For group-level clusters, the cluster “Environments” view has been extended to instance-level clusters.

The “Environments” section of the cluster page provides an overview of all the projects that are making use of the Kubernetes cluster, including the deployments/environments that have been provisioned and the numbers of pods used by each environment.

S/MIME is now configurable in the GitLab Helm chart

Sending emails with an S/MIME signature improves security by reducing the surface area for phishing, man-in-the-middle, and other attacks. While the ability to sign notification emails with S/MIME was added to Omnibus in 12.3, it wasn’t possible to configure S/MIME when installing GitLab on Kubernetes. Now, in 12.4, S/MIME parameters for GitLab email notifications can be configured as a global setting for the GitLab helm chart.

Upgraded Kubernetes Cert-Manager Application When Installed via Kubernetes Integration

Keeping security certificates for your Kubernetes-deployed apps updated ensures your applications are securely served without interruption. Starting with GitLab 12.4 you can now upgrade your Cert-Manager application using the GitLab Kubernetes integration. To upgrade to the latest GitLab-supported version, navigate to the cluster page from Operations > Kubernetes, then uninstall and reinstall Cert-Manager.

Omnibus improvements

  • GitLab 12.4 includes Mattermost 5.15, an open source Slack-alternative. This version of Mattermost is focused on quality improvements.
  • OpenSSL has been updated to version 1.1.1d, which fixes a number of CVEs. For information about the changes introduced in this minor release, visit the OpenSSL website.
  • An option has been added to skip database backups during an upgrade. Database backups can extend the time required to complete an upgrade, and in some cases, you may want to skip this step so that the upgrade finishes quicker. For details on how to skip automatic database backups during upgrades, see the Omnibus upgrade documentation. If you skip the automatic backups, make sure you create your own before upgrading.


Versions of Cert-Manager prior to 0.8.0 will be blocked by Let's Encrypt starting Nov. 1st

Prior to GitLab 12.4, the Kubernetes integration provided users the option to install Cert-Manager v0.5.2 onto their Kubernetes cluster. Let’s Encrypt will block requests from versions of Cert-Manager less than 0.8.0 starting on November 1st, 2019. To resolve this, users must uninstall Cert-Manager then install Cert-Manager again. You should consider backing up any additional configuration prior to upgrading in the event of data loss.

Removal date: Nov. 1, 2019

Move protected paths configuration from `gitlab.rb` to the GitLab UI

The configuration of protected paths has been moved to the GitLab UI so that there is a single place to configure all settings related to throttling. Previously, user and IP limits were set in the UI, and protected paths were set in /etc/gitlab/gitlab.rb. Configuring protected paths in gitlab.rb has been deprecated in GitLab 12.4 and is scheduled for removal in GitLab 13.0. For details on how to configure protected paths in the UI, and migrating protected path throttles from Omnibus GitLab 12.3 (or earlier) to the UI, see the protected paths documentation.

Removal date: GitLab 13.0

Elasticsearch 5.6 will no longer be supported

As we continue to improve and enhance our integration with Elasticsearch, support for Elasticsearch 5.6.x will end with the release of GitLab 12.7. Elasticsearch 5.6 has also reached its end of life with the release of Elasticsearch 7.x.

Updated version requirements for GitLab 12.7 will include support for only Elasticsearch 6.x. At this time there is no timeline for support of Elasticsearch 7.x with GitLab; you can follow this issue for updates. GitLab recommends self-managed customers upgrade to ElasticSearch 6.x.

Removal date: January 22, 2020

Deprecating support for openSUSE Leap 15.0

openSUSE 15.0 reaches end of life at the end of November 2019. Support for openSUSE 15.0 will be dropped in GitLab 12.5. Issue 4404 tracks the work to build packages for openSUSE Leap 15.1.

Removal date: GitLab 12.5

Important notes on upgrading to GitLab 12.3

  • GitLab 12.4 now installs Knative 0.7 as a GitLab Managed App. Note: GitLab Serverless is still in alpha. If you run into issues with previous Knative versions, please reach out to the GitLab support.

  • Starting with GitLab 12.4, the Kubernetes integration will install Cert-Manager v0.9.1. If you installed Cert-Manager via the Kubernetes integration previously, then you will be on an older version. Older versions will be blocked by Let’s Encrypt starting November 1st, 2019. See more info on the Cert-Manager deprecation notice. GitLab 12.3 upgrades Cert-Manager to v0.9.1 when installing it through the Kubernetes integration. If you are using an older version of Cert-Manager (installed through the Kubernetes integration) you will need to uninstall the old version and install the latest version as older versions will be blocked by Let’s Encrypt starting November 1st, 2019. See more info on the Cert-Manager deprecation notice.

  • To help with the larger migrations we have introduced background migrations for this release. Background migrations are Sidekiq jobs that will run asynchronously. For these migrations took around 36 hours to complete, and no side effects were expected nor present. To find the approximate time (in hours) it will take to complete these migrations on your instance run the following command from a Rails console: (Project.count.to_f / 300_000).ceil. You can check the status of background migrations by running this command from a Rails console:'background_migration').size.


Please check out the changelog to see all the named changes:


If you are setting up a new GitLab installation please see the download GitLab page.


Check out our update page.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Core: For small teams, personal projects, or GitLab trials with unlimited time.
  • Starter: For co-located teams with few projects who need professional support.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project. Private projects get access to Free features, public projects get access to Gold features.
  • Bronze: For teams that need access to more advanced workflow features.
  • Silver: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Gold: Great with many CI/CD jobs. Every public project get the features of Gold for free irrespective of their plan.

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg