Mar 22, 2021 - Christen Dybenko  
13.10

GitLab 13.10 released with Admin Enhancements and Vulnerability Management

GitLab 13.10 released with Admin Enhancements, Programatic Vulnerability Management, and much more!

GitLab 13.10 is now available! This month, we’ve focused on scalability and manageability across the product so you can iterate and innovate faster, with greater security and fewer headaches. 13.10 offers administrative enhancements to help scale DevOps in your org, Geo package integrity verification to improve Disaster Recovery, vulnerability management automation to apply efficiency and consistency to security processes, and—as always—a ton of fantastic contributions from the wider community. These are just a few of the 40+ new features and improvements in this release.

Scaling DevOps

Managing a growing DevOps org is challenging. GitLab 13.10 introduces several new features to automate routine tasks, boost your efficiency, and grow DevOps within the organization without losing control. We’ve leveled up support for DORA metrics with a new API to track lead time for changes (via merge requests) on the project level, as well as Deployment Frequency metrics via API at the group level, so you can track and identify blockers across a portfolio of projects.

When issues do arise, we've added tools to help you integrate and manage alerts from multiple monitoring solutions. 13.10 also enhances disaster recovery (DR) for customers using GitLab Geo by automatically verifying the data integrity of replicated Package Registries and replicating group wikis. And finally, we're extremely excited to announce General Availability of GitLab Runner Operator on Red Hat OpenShift, bringing GitLab to even more platforms!

Scaling Vulnerability Management

In 13.10, our security team has focused on reducing the overhead of managing and sharing vulnerabilities. Bulk Status Updates allow security teams to modify the status of multiple vulnerabilities simultaneously. To help you identify and triage relevant information quickly, we've introduced clickable file and line number links in vulnerability reports that will deep-link you directly to relevant vulnerability details. We've also enhanced the interactivity of the vulnerability trends chart to make it easier to find and share information.

Wider community contribution highlights

Every month we receive hundreds of contributions from the wider community, and in addition to this month's MVP, we'd like to show our appreciation to a few of our many outstanding contributors.

Ongoing thanks to Yogi for dozens of contributions to 13.10, as well as months of amazingly consistent contributions and throughput. You are an example of iteration in action, and you continue to tackle challenges with boring solutions that deliver amazing results!

Thank you, Daniel Schömer for your iterations toward a more consistent UX in project settings!

Thanks to Felix Haase for his work on cloning projects from within Visual Studio Code!

Thank you to @KevSlashNull for his work enabling one-click opening of projects in VS Code!

GitLab is an Open DevOps Platform, and a huge reason for that is you. We're a community, and in 13.10 alone we enjoyed over 250 merged wider community contributions. Selecting one MVP wasn't easy; thank you all for your professionalism and hard work.

And so much more!

Some of our favorite quality of life improvements in 13.10 include:

Read on for more features, performance enhancements and changes! To preview what's coming in next month’s release, check out our Upcoming Releases page and our 13.11 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Diego Louzán

Admin Mode wouldn’t have happened without a heroic, ongoing effort from Diego Louzán. This feature has been in the making for a year! With this feature, GitLab administrators can use their account without administrator entitlements unless they re-authenticate to trigger admin mode. This provides an additional level of protection to administrative operations and will be really useful in regulated industries. On behalf of administrators everywhere and all the sleepless nights we’ll avoid, we tip our hats to you!

Diego submitted a complete package, and patiently addressed everyone’s concerns – and ideas “above and beyond” what was absolutely necessary. Diego collaborated extremely well with reviewers & maintainers on what was a big change - involving backend, frontend, database, and documentation. Admin Mode is feature flagged until 13.11, but since he completed the project during 13.10, we wanted to recognize Diego right away!

Key features released in GitLab 13.10

GitLab Runner for Red Hat OpenShift GA

The GitLab Runner Operator is generally available in the Red Hat OpenShift Container Platform. To install GitLab Runner on OpenShift, you can use the GitLab Runner Operator, which is available from the stable channel in the OperatorHub. The Container Platform is a web console for OpenShift cluster administrators to discover and select Operators to install on their cluster. We are also developing an Operator for GitLab, so stay tuned to future release posts for those announcements.


Integrate any IT alerting tool with GitLab

Alert integrations are a critical part of your Incident Management workflows. It’s difficult to manage integrations between tools, especially when several monitoring tools like Nagios, Solarwinds, etc. alert on your services. These integrations notify you and your team of incidents, so it’s critical for them to be easy to set up and maintain.

In this version of GitLab, you can create multiple HTTP endpoints with unique auth tokens for each integrated monitoring tool. When you set up an HTTP endpoint with a unique auth token for each monitoring tool, your team can manage each tool separately without affecting alerts from other tools nor take down all of your alerting by resetting a single auth token!

For each HTTP endpoint you create, you can transform each external alert’s unique format in the GitLab user interface, and ensure your alerts display relevant data in the right places. Submit a sample payload for the tool by pasting it into GitLab, map fields from the payload to GitLab alert attributes, and your alerts will present consistent information regardless of their source.

Integrate any IT alerting tool with GitLab

DORA4-based lead time for changes

Measuring the efficiency of your software development lifecycle is an important step to grow DevOps adoption for any organization. In the previous milestone, we added support for DORA4-based Deployment Frequency. In this release, we are excited to announce the support of a new API for lead time for changes (via merge requests) on the project level. The lead time for changes gives you an indication of how long it takes for code to be committed and deployed to your production environment. Understanding and tracking this data is a great starting point in your journey to continuous improvement in your DevOps process.

DORA4-based lead time for changes

Create a release from an existing tag

Previously, creating a release was supported only for new tags. In GitLab 13.10, you can now create a release by selecting an existing tag, something that will give you more flexibility when planning releases.

Create a release from an existing tag

Define environment type in .gitlab-ci.yml

In GitLab 13.10, we are introducing a new .gitlab-ci.yml environment type keyword which will allow you to explicitly define the environment type and name. Supported environment types can be: production, staging, testing, development, or other. This is a first step towards group level environment management and the ability to create separation of duties for deployments to production environments. This new configuration will also provide users with much more flexibility in the production environment naming convention traditionally used, that is used to determine different metrics in GitLab, such as Dora4 metrics and Value stream Analytics.

Define environment type in .gitlab-ci.yml

API fuzz testing graphical configuration screen

We know that it can be challenging to get started with API fuzz testing. Configuration settings can be difficult to remember and code into your pipeline. To make this easier, we are introducing a new user interface to simplify your API fuzz test settings!

You can now enter the needed settings in the new API fuzz testing configuration screen rather than directly within a pipeline file. Once you are done, the page will give you a snippet you can copy into your .gitlab-ci.yml file and even start a merge request if you wish. This helps guide you to add the correct configuration to your own pipelines so you can get started with API fuzz testing more quickly and more efficiently than before.

API fuzz testing graphical configuration screen

View Jira issue details in GitLab

Users of our Jira issue list feature can now view the details of an issue directly inside of GitLab! This MVC enables developers to see the details, labels, and comments on an issue, giving them the ability to stay in GitLab while working on Jira issues.

Our goal is to empower developers to stay inside of GitLab during the majority of their day, and this is now one less trip to Jira you’ll have to make.

In GitLab 13.10, this feature is available if you enable a feature flag. This feature will be enabled by default in GitLab 13.11.

View Jira issue details in GitLab

Improvements to the GitLab.com for Jira Cloud Application

You can now sync your Jira Cloud project data with GitLab by using the GitLab.com for Jira Cloud application, available on the Atlassian Marketplace. This plugin displays information about your branches, commits, merge requests, deployments, and feature flags in the Jira Development Panel. Use it to see the current status of work in progress, then quickly navigate back to those pages inside of GitLab.

To make these features easier to use, we’ve made significant improvements to the initial setup process over the last few milestones, and now getting your GitLab namespaces connected is easier than ever. To get started, check it out on the Atlassian Marketplace.

Improvements to the GitLab.com for Jira Cloud Application

Use ‘parallel: matrix’ with trigger jobs

You can use the parallel: matrix keywords to run jobs multiple times in parallel, using different variable values for each instance of the job. Unfortunately, you could not use it with trigger jobs. In this release, we’ve expanded the parallel matrix feature to support trigger jobs as well, so you can now run multiple downstream pipelines (child or multi-project pipelines) in parallel using different variables value for each downstream pipeline. This lets you configure CI/CD pipelines that are faster and more flexible.

Use 'parallel: matrix' with trigger jobs

Group-level API support for Deployment Frequency

In gitlab#279039, we added support for Deployment Frequency at the project level. This release extends support for this API to the group level. This allows users to get a full picture of the Deployment Frequency across projects and teams, so they can assess their efficiency more accurately.

Group-level API support for Deployment Frequency

Other improvements in GitLab 13.10

Admin Mode: Re-authenticate for GitLab administration

GitLab now includes Admin Mode, which helps admins work safely from one account. When Admin Mode is not active, admins have the same privileges as a regular user. Before running administrative commands, admin users must reverify their credentials. Admin mode increases instance security by protecting sensitive operations and data. This feature is available behind feature flag :user_mode_in_session.

Admin Mode: Re-authenticate for GitLab administration

Optional enforcement of SSH key expiration

SSH keys have had an optional expiration date since GitLab 12.9, however, there was no way to enforce that date.

Administrators can now enforce SSH key expiration dates on their GitLab instances. Enforcing SSH key expiration will immediately make all expired SSH keys un-usable.

View epics on a board (MVC)

If you work on epics in GitLab, it can be tough to visualize your epics’ workflow status. Often, when drafting or writing epics, you might want to use labels (like Open, Doing, or Done) to keep tabs on the next steps when creating your project plan.

In this release, we took our awesome Issue Boards feature and optimized it for viewing epics. You can now visualize the workflow status of your epics on an epic board by applying labels or scoped labels to them.

We are releasing this early version of Epic Boards in 13.10, so we can start gathering customer feedback. We will follow it up with MVC 2 and MVC 3, which will achieve parity with Issue Boards.

Read about the current limitations in the Epic Boards documentation. We are targeting the full release of Epic/Program boards on the parent epic. Please leave feedback about your experience in the feedback issue.

View epics on a board (MVC)

Automatically retarget merge requests

You’ve likely needed to create chained merge requests where the first merge request targets a feature branch, which in turn already has a merge request targetting main. This is a common workflow to help keep merge requests small for review and indicate merge order. However, if a merge request in the chain is merged and its branch is deleted, any subsequent merge request is no longer mergeable, as its target is missing.

GitLab now automatically updates the target of merge requests where the original target branch has been deleted. This ensures merge requests can continue to be reviewed and merged, and manual action isn’t required on the part of merge request authors or reviewers.

Collaborating on long files is easier when you can share a link to a specific line of code. Previously, you could only link to a line number when viewing a file in the repository, but now you can also link to specific lines of code in the context of editing a file.

To get a link to a specific line, click the icon in the gutter next to the line number, or append #L followed by the line number to the edit URL. The link will open the editor, scroll to the line, and highlight it for you. Try it out in the single-file editor, the Web IDE, and the Pipeline Editor!

Tip: you can even create a link to multiple lines by appending a range to the link, like #L87-98, even though the UI doesn’t support creating these (yet).

Deep link directly to lines of code

Open project in Visual Studio Code

When working on a project for the first time, you often clone that project locally to start contributing via your local editor. This process involves a few steps: initially getting the path for cloning, finding a place on your system to clone the project, and then opening that project inside your editor of choice.

When clicking the Clone dropdown for a project, you can now choose to open the project in Visual Studio Code (VS Code). Cloning is now a one-click experience: clone the project and then immediately start work in VS Code.

Thanks @KevSlashNull for your contribution!

View your snippets at snippets.gitlab.com

Now you can visit snippets.gitlab.com to access your snippets dashboard. This easy-to-remember URL is the quickest way to view all the snippets you’ve created and discover other public snippets.

Merge Request test summary usability improvements

Increasing the number of tests or custom metrics in a pipeline gives you additional confidence and information. However, increasing these to a large number has also come with a degraded visual experience of the Merge Request page. The Merge Request test summary widget has been improved so you can better differentiate between the different test jobs in the widget, making it easier to identify which job contains failed tests.

It has also been challenging to understand why a junit.xml file was not parsed without errors being presented. Now you can see parsing errors in the Test Summary widget, as well as the Unit Test report, to identify and resolve structural issues and see test results in GitLab.

The Metrics Reports widget (Premium and Ultimate) is now sorted so new, changed, and unchanged metrics are all together, making the experience of finding metrics that have changed as part of the Merge Request more intuitive.

Merge Request test summary usability improvements

Ease the npm package naming convention

When publishing npm packages to your project’s Package Registry, you previously had to name your package with @scope/package-name so that the scope was an exact match to the root workspace of your project, including the case. For example, if your project path was /Acme/project_a, when you published a package, it had to have Acme as the scope.

For many of you, this meant using a capital letter. However, the public npm registry does not allow capital letters in the scope. So, you were forced to either change your group name, which might have had unintended side effects, or you might have chosen to not use the GitLab Package Registry.

Moving forward, we will no longer enforce this naming convention for the project-level endpoint. Huzzah! Now you can name your packages and scope whatever you want.

It’s worth noting that using the instance-level endpoint will still require you to use the exact (case-sensitive) root of your namespace as the @scope.

Use the Dependency Proxy with ‘containerd’ and Docker 20+

The GitLab Dependency Proxy is a local proxy you can use for your frequently-accessed upstream images from Docker Hub. In the case of CI/CD, the Dependency Proxy receives a request and returns the upstream image from a registry, acting as a pull-through cache. This helps to reduce your CI minutes and increase reliability.

However, you haven’t been able to pull images by digest, which as an immutable identifier ensures you are using the exact version of a specific image and tag. Since both containerd and Docker 20+ depend on pull-by-digest, this meant that many of you were blocked from using the Dependency Proxy.

We are happy to say that you can now pull your container images from Docker Hub by digest. You can use the Dependency Proxy by adding the URL to your .gitlab-ci.yml file, manually pulling the image from the command line, or using a Dockerfile. Check out the documentation and start saving time on your builds.

API fuzz testing supports OpenAPI v3 files

API fuzz testing now supports OpenAPI v3 specification files. This allows you to directly use the OpenAPI specifications your project already has without needing to downgrade them to OpenAPI v2. You provide OpenAPI v3 files in the same way you would provide an OpenAPI v2 file, as part of the FUZZAPI_OPENAPI variable in your .gitlab-ci.yml file.

Many of GitLab’s security scanners output a file and line number where a potential vulnerability is detected. Users can see this information in the form of a clickable link when viewing a vulnerability’s details. The link will take the user directly to the file and line number inside the repository for the default branch. This same information is also displayed on the Vulnerability Report. However, the file names were not clickable, requiring that you open a vulnerability’s details page to access the link.

This enhancement brings the convenience of linked filenames to the Vulnerability Report. From a Project, Group, or Security Center Vulnerability Report, you can go directly to the affected file and line number from any vulnerability reported from a scanner that outputs this information. Because you no longer need to first open each vulnerability record, it is much faster to do things like open multiple referenced lines of code in separate tabs for speedy triage.

Clickable file and line number links on Vulnerability Report

Support Java 15 for Dependency Scanning

For customers using Java 15 you will be happy to know that you are now supported by our Dependency Scanning analyzers. Please set the DS_JAVA_VERSION environment variable to 15 to leverage this enhancement.

Collapsible list of deployed environments in merge requests

Merge Requests (MRs) are the single source of truth for developers. MRs contain everything you need as a developer in order to commit code changes, collaborate, complete code reviews, and merge code to the target branch.

To improve usability as a part of this release, if your MR is now deployed to more than four deployments, the list of deployments will be collapsed. This is especially useful in situations where you have numerous deployed environments that cause your MR page to be overly lengthy and require you to scroll up and down the page to see all of the content.

Collapsible list of deployed environments in merge requests

Configure the Kubernetes Agent Server as part of the core GitLab configuration

While GitLab administrators could install the Kubernetes Agent Server along with their GitLab instance, until now they lacked many configuration options. With this release, GitLab administrators can specify the Agent Server’s external and internal URLs as well as their operational status (enabled or disabled) in the core GitLab configuration file (config/gitlab.yaml). GitLab will use these configuration values for every interaction with the Agent Server.

The Kubernetes Agent Server is also now available on GitLab.com. We are progressively making this feature available to more projects over time.

Geo supports replicating Group wikis

Geo now supports replicating Group Wikis to secondary sites, allowing distributed teams to access them from the closest Geo site, which reduces latency and improves the overall user experience. Additionally, this data can also be restored from a secondary site when failing over to that site.

We currently don’t support verification of these assets, but future support is planned.

Geo verifies replicated package files

Geo automatically verifies the data integrity of replicated Package Registries. This ensures that packages are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.

Geo’s verification capabilities are implemented generically in Geo’s replication framework and we are planning to bring file verification to all other replicated data types e.g. LFS files or attachments.

Omnibus improvements

  • ARM64 packages are now available for Debian 10.
  • GitLab RPM Packages are now signed with the SHA256 digest, instead of MD5. This change improves signature strength and allows the packages to be installed on FIPS-enabled systems.
  • GitLab’s official AWS AMIs and Omnibus Docker images are now based on Ubuntu 20.04.
  • The allowlist of host headers accepted by GitLab is now configurable. By default, everything is allowed.
  • The SMTP configuration for the bundled Grafana service is now configurable, enabling emails to be sent to users.
  • registry has been upgraded to v3.1.0, openssl to 1.1.1j.
  • GitLab 13.10 includes Mattermost 5.32.1, an open source Slack-alternative whose newest release includes custom collapsible channel categories, some breaking changes, and other improvements. This version also includes security updates and upgrade from earlier versions is recommended.

Horizontal navigation for Value Stream Analytics

The vertical value stream stages in the Group-level value stream analytics have been replaced with a horizontal layout to help visualize the flow of work through stages of a value stream. This change creates more space on the page to add additional graphs and metrics in the future. In addition, value streams are now much easier to create and edit using a new form that allows the creation of a value stream and all of the stages in one single step. In the form, pre-configured stages can be added, or custom stages created. This is a much improved user experience compared to the previous multi-step process. When editing your value stream, all of the start and end events for each stage are clearly visible in the form, helping you understand how the value stream has been mapped end to end.

Horizontal navigation for Value Stream Analytics

Search and autocomplete by full name in comment mentions

It’s not common for GitLab users to use their full name as their username. This makes it difficult to find the individuals you want to @ mention because the autocomplete doesn’t do a great job matching both full name or username. As a first step towards making autocomplete smarter, you can now more easily search for people based on their username or full name.

API description templates: Issues and Merge Requests

Setting the default description template for issues and merge requests can be valuable to ensure users provide the right content when creating these items. When you have many projects configuring each of these templates or updating them across all your projects, the process can be manual, error-prone, and time-consuming.

With the new issues_template and merge_requests_template attributes available for the projects API, you can automate setting and keeping these templates up-to-date for all of your projects.

Clone project inside Visual Studio Code

When using the Visual Studio Code IDE (VS Code) you may need to work on a code repository that you don’t have on your local machine. Before, cloning a project required several steps away from your editor: find the project in GitLab, copy its clone link, clone it into your local machine, and finally open it in VS Code.

With the GitLab Workflow extension you can now use the Git: Clone command in VS Code to do all of that without leaving your editor. Use this command to search for projects in GitLab and clone them so you can quickly begin contributing.

Thanks Felix Haase for the contribution!

Notify participants when merge request is marked ready

When you have finished preparing your merge requests you can signal it is ready for review by marking it as ready and removing the draft status. However, marking a merge request as ready did not inform other participants that your merge request is ready for their review.

Now, when marking a merge request as ready, a notification is sent to participants of the merge request. Alerting merge request participants that your merge request is ready for review helps to shorten cycle time and get your contribution merged faster.

Show number of files in a snippet in the list view

GitLab 13.5 introduced the ability to create snippets that contain multiple files. However, there was no way for you to identify these multi-file snippets in the list view. You needed to open each snippet to distinguish between similarly-named snippets or to infer the type of data included by how many associated files it contains.

Now, the number of files contained in each snippet is displayed in the list view so you have access to this information before opening it.

Show number of files in a snippet in the list view

GitLab Runner 13.10

We’re also releasing GitLab Runner 13.10 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Predefined CI/CD variables for job start and pipeline created timestamps

Previously, if you wanted to reference the exact date and time when a job started or a pipeline was created, you needed to retrieve these timestamps in your scripts. Now they are readily available as predefined CI/CD variables by using CI_JOB_STARTED_AT and CI_PIPELINE_CREATED_AT, provided in the ISO 8601 format and UTC time zone.

Thanks to @Winkies for this contribution!

Easily access Gradle setup and install commands

You can use the GitLab Package Registry to publish your Java dependencies with Maven or Gradle. Once published, you can navigate to the Package Registry UI to view the package and its related metadata. When viewing a specific package, you have access to snippets for configuring and installing the package using Maven. But we did not provide the correlated commands for Gradle users.

Moving forward, you can now copy both Maven and Gradle commands, making you more efficient. Simply navigate to your project or group’s package registry, click a specific Java package, and copy the snippets. Groovy, right?

Thank you to @Cromefire_ for helping us to iterate on the content and design for this feature!

Easily access Gradle setup and install commands

API fuzz testing parameter override

When performing API fuzz testing, it’s a common problem that various fields in the API request will need to be updated or added to allow the API request to be successful. Such changes are needed to support API authentication, environment-specific data, etc.

This release expands on our existing override support, allowing changes to headers, cookies, query parameters, form data, JSON body data, and XML body data. Changes can be made using static values provided at runtime or dynamically by providing a script that is called to provide the values while the scan is running. Dynamic changes using a script allow updating authentication tokens that expire quickly.

Customizing these attributes both improves the quality of the test and ensures it can complete successfully.

In 13.6, we released a new Project Security Dashboard with a vulnerability trends chart. This chart provides a historical view of vulnerability counts by severity over the past 365 days. It provides valuable insights into a Project’s security health trends.

We’ve enhanced the chart to include new interactive elements to make it more effective and efficient to use. You can now zoom in on a selected section of the chart, and zoom out to the default view. You can also export an SVG image of the chart for use in external documents.

Add icons to the Vulnerability Trends Chart

Static Analysis Analyzer updates

GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 13.10. These updates bring additional coverage, bugfixes, and improvements.

  • ESLint updated to version 7.21.0: MR - Changelog
  • MobSF updated to version 3.3.3: MR - Changelog
  • njsscan updated to version 0.2.3: MR - Changelog
    • notable change: njsscan will skip files that are over 25MB
  • GitLeaks updated to version 7.3.0: MR - Changelog
  • spotbugs updated to version 4.2.2: MR - Changelog
  • pmd updated to version 6.32.0: MR - Changelog
  • sobelow updated to version 0.11.1: MR - Changelog
  • gosec updated to version 2.7.0: MR - Changelog

If you are including the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations.

Vulnerability bulk status updates

It is currently possible to select and dismiss multiple vulnerabilities in bulk from a Vulnerability Report. This is helpful in quickly removing redundant occurrences or false positives. However, you must still open up individual vulnerability details to change status to anything other than Dismissed. This is inefficient for doing routine activities such as resolving all vulnerabilities no longer detected by securing scanners.

This bulk actions enhancement addresses this limitation. Selecting one or more vulnerabilities from a Vulnerability Report will now present the option to set any status. You can even move vulnerabilities back to Detected if they need further triage evaluation. Combined with the filtering capabilities, it is easier than ever to isolate and take action on a specific subset of vulnerabilities all at once.

Vulnerability bulk status updates

Notifications settings for ‘merge when pipeline succeeds’

Previously, when Merge when pipeline succeeds (MWPS) was set to on, all participating users within the merge request got a notification about this event. With GitLab 13.10, you can now choose to unsubscribe from the MWPS notification events with a new custom setting, allowing you to reduce unnecessary noise. Thanks to Ravishankar Gnanaprakasam for a great community contribution!

If you are planning on enabling Advanced Search, you need to know the estimated size of the index so you can prepare sufficient storage in Elasticsearch. Prior to 13.10, this required a few different steps to determine the total combined size.

To make this readily accessible, we have added a Rake command which aggregates all of the indexed content and multiplies by .5 to give an estimated size that is recommended for Elasticsearch.

Elasticsearch cluster size estimate in Advanced Search

Geo trusts a secondary site by default

A Geo secondary site uses an OAuth application on the primary site to perform authentication. When a new Geo secondary site was set up, the primary site did not trust the secondary site by default. This meant any user would have to confirm separately that the secondary could be trusted when connecting for the first time.

In GitLab 13.10, the primary site trusts a secondary site by default as it is provisioned by GitLab. This eliminates an unneeded and potentially confusing OAuth dialog.

GitLab chart improvements

Run GitLab on small instances with 2GB RAM

GitLab can be deployed using one of the reference architectures supporting from a few hundred, to tens of thousands of users. However, many community members choose to run GitLab only for personal use or for small teams. In those situations, it may be desirable to run GitLab on a small cloud instance to save costs or, for example, to use a Raspberry PI 4 with 2GB RAM.

We’ve updated our documentation to include detailed instructions on how to run GitLab in a memory constrained environment with a minimum of 2GB of RAM and 1GB of swap. This configuration makes a few opinionated choices to reduce memory consumption, such as running Puma in single mode (saves ~300-400MB) and disabling the monitoring stack (saves another 200MB). We’ve also tweaked a few other settings for Gitaly and how GitLab handles memory allocation.

This configuration allows GitLab to support up to 5 developers with individual Git projects no larger than 100MB. For larger team sizes or if these settings are not acceptable, we still recommend at least 4GB of RAM (for up to 500 users) for best performance. Please see the reference architectures for further guidance.

Performance improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!

In GitLab 13.10, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.10 are:

Deprecations

API fuzzing configuration files moving to .gitlab folder

In GitLab 14.0, API fuzz testing configuration files, such as .gitlab-api-fuzzing.yml, should be placed in your repository’s .gitlab directory. This helps keep your repository organized. Storing these files in your repository’s root will be deprecated.

Your .gitlab-api-fuzzing.yml should also be renamed to .gitlab-api-fuzzing-config.yml in GitLab 14.0. No other changes will be required in the configuration files. You can continue using the existing configuration files, but GitLab 14.0 will require you to move them to the .gitlab directory and rename them. Starting in GitLab 14.0, GitLab will not check the old location for configuration files.

Planned removal date: June 22, 2021

Auto DevOps: Stable Auto Deploy template renewal

In GitLab 14.0, we will renew the Auto Deploy CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 auto-deploy-image. This latest template is opt-in. Unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the v1 auto-deploy-image.

Since the v1 and v2 versions are not backwards compatible, your project might encounter an unexpected failure if you already have a deployed application. Please follow the upgrade guide to upgrade your environments. You can also start using the latest template today by following the early adoption guide.

Planned removal date: June 22, 2021

CI/CD pipeline behavior changes in GitLab 14.0

In GitLab 14.0, we intend to make some changes to the behavior of CI/CD pipelines to improve performance and resource usage:

  • Scheduled pipeline that run very frequently can impact an instance’s performance. In GitLab 14.0, the frequency of scheduled pipelines will be subject to GitLab application limits. For self-managed instances, admins will have the option to change or disable these limits, which can reduce the problems caused by performance-impacting cron patterns in pipeline schedules.
  • In some edge cases, users were accidentally triggering both branch pipelines and merge request pipelines at the same time, wasting resources. We are working to add a default workflow: rule in GitLab 14.0 to reduce the risk of this happening. Users with pipelines configured to rely on this behavior can easily override the new default with their own workflow: rule to re-enable the previous behavior.

Planned removal date: June 22, 2021

Code Quality Rubocop support changing

Currently, by default, the Code Quality feature does not provide support for Ruby 2.6+ if you’re using the Code Quality template.

To better support the latest versions of Ruby, the default Rubocop version is being changed to add support for Ruby 2.4 through 3.0. As a result, support for Ruby 2.1, 2.2, and 2.3 will be dropped. You can reenable support for older versions by customizing your configuration.

Relevant Issue: Default codeclimate-rubocop engine does not support Ruby 2.6+

Planned removal date: June 22, 2021

Container Scanning Engine Clair

GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open source Clair engine for container scanning. Clair was deprecated in GitLab 13.9. For any 13.x release, customers can continue to use Clair without making any changes to their CI files; however, note that GitLab will no longer update or maintain that scanning engine. Beginning in the 14.0 release, Trivy will become the new default scanner and will receive regular updates and the latest features. Customers are advised to review their CI files in advance of the 14.0 release and to follow these instructions to ensure that their container scanning jobs continue to work. Customers can provide feedback and get additional details on our open deprecation issue.

Planned removal date: June 22, 2021

DAST environment variable renaming and removal

GitLab 13.8 renames multiple environment variables to support their broader usage in different workflows. In GitLab 14.0, the old variables will be permanently removed and will no longer work. Any configurations using these variables must be updated to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly. These variables are:

  • DAST_AUTH_EXCLUDE_URLS becomes DAST_EXCLUDE_URLS.
  • AUTH_EXCLUDE_URLS becomes DAST_EXCLUDE_URLS.
  • AUTH_USERNAME becomes DAST_USERNAME.
  • AUTH_PASSWORD becomes DAST_PASSWORD.
  • AUTH_USERNAME_FIELD becomes DAST_USERNAME_FIELD.
  • AUTH_PASSWORD_FIELD becomes DAST_PASSWORD_FIELD.
  • DAST_ZAP_USE_AJAX_SPIDER will now be DAST_USE_AJAX_SPIDER.
  • DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED will be removed, since the feature is being removed.

Planned removal date: Jun 22, 2021

Default Browser Performance testing job will be renamed in GitLab 14.0

Browser Performance Testing currently runs in a job named performance by default. With the introduction of Load Performance Testing in GitLab 13.2, this naming could be confusing.

To make it clear which job is running Browser Performance Testing, the default job name will be changed from performance to browser_performance in the template in GitLab 14.0.

Relevant Issue: Rename default Browser Performance Testing job

Planned removal date: June 22, 2021

Deprecate Container Registry log formatters

Currently, GitLab supports:

  • Text, JSON, and logstash log formatting for app logs.
  • Text, JSON, and combined log formatting for access logs.

We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.

Planned removal date: February 22, 2021

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Planned removal date: February 22, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to:

  • Remove the redis.pool.maxidle and redis.pool.maxactive settings.
  • Add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused) settings.

Planned removal date: February 22, 2021

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Planned removal date: February 22, 2021

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Planned removal date: February 22, 2021

Deprecate Container Registry support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.

We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.

Planned removal date: February 22, 2021

Deprecate disk source configuration for GitLab Pages

GitLab Pages API-based configuration has been available since GitLab 13.0 and will replace the disk source configuration, which will be removed in GitLab 14.0. We recommend that you move away from using disk source configuration and move to gitlab for an API-based configuration, since disk will no longer be supported and cannot be chosen. You can migrate away from the ‘disk’ source configuration by setting gitlab_pages['domain_config_source'] = "gitlab" in your gitlab.rb/etc/gitlab/gitlab.rb file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.

Planned removal date: June 22, 2021

Deprecate pulls that use v1 of the Docker registry API

GitLab disabled pulls via the Docker registry v1 APIs on January 22, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

  1. Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
  2. If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

Planned removal date: February 22, 2021

Deprecating Service Templates

Service Templates are now deprecated and scheduled to be removed in GitLab 14.0. They were used to apply identical settings to a large number of projects, but they only did so at the time of project creation.

While they solved part of the problem, updating those values later proved to be a major pain point. Project Integration Management solves this problem by enabling you to create settings at the Group or Instance level, and projects within that namespace inheriting those settings.

Planned removal date: June 22, 2021

Deprecating global SAST_ANALYZER_IMAGE_TAG in SAST CI template

With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity into our release process. Currently GitLab shares a major version number for all our analyzers and tools. This requires all tools to share a major version and prevent the use of semantic version numbering. Beginning in 14.0 GitLab SAST will deprecate the SAST_ANALYZER_IMAGE_TAG global variable in our managed SAST.gitlab-ci.yml CI template in favor of analyzer job variable setting the ‘major.minor’ tag in the SAST vendored template. Each analyzer job will have a scoped SAST_ANALYZER_IMAGE_TAG variable which will be actively managed by GitLab and set to the ‘major.minor’ tag for the respective analyzer. To pin to a specific version you simply change the variable value to the specific version tag. If you override or maintain custom versions of SAST.gitlab-ci.yml you will want to update your CI templates to stop referencing the global SAST_ANALYZER_IMAGE_TAG and move it to a scoped analyzer job tag. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. This change will allow you to instead override with a pinned major.minor version to more granular control future analyzer updates. This change will happen with GitLab 14.0 releasing June 22, 2021. This deprecation and planned removal changes our previously annouced plan to Pin the Static Analysis tools.

Planned removal date: June 22, 2021

Deprecation of disk/NFS storage for GitLab Pages

To make GitLab Pages cloud-native compatible, starting in GitLab 14.0, we’re changing the underlying storage format used by GitLab Pages to object storage. Your migration to the new storage format is designed to be automatic, however, it may require some human intervention. To ease this transition into object storage, a temporary flag gitlab_pages['use_legacy_storage'] = true will be available from GitLab 14.0 to 14.3, but it will be removed in GitLab 14.4. In 13.11 you will be able to migrate to the new architecture earlier and test it in your environment prior 14.0.

Planned removal date: June 22, 2021

Deprecation of release description in the Tags API

GitLab 14.0 will remove support for the release description in the Tags API. You’ll no longer be able to add a release description when creating a new tag. You’ll also no longer be able to create or update a release through the Tags API. Please migrate to use the Releases API instead.

Planned removal date: June 22, 2021

Deprecations for Dependency Scanning

We are reiterating the upcoming deprecations for Dependency Scanning in 14.0, as mentioned in 13.9 and this blog post.

Previously to exclude a DS analyzer, you needed to remove it from the default list of analyzers and use that to set the DS_DEFAULT_ANALYZERS variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. As a result we ask you to migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS when it is available. Read about it in issue #287691.

Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE env variable. This is not documented properly and its naming is inconsistent with the equivalent BUNDLER_AUDIT_UPDATE_DISABLED variable. As a result we ask you to migrate from GEMNASIUM_DB_UPDATE to GEMNASIUM_UPDATE_DISABLED when it is available. Read about it in issue #215483.

Planned removal date: June 22, 2021

Expired SSH keys disabled by default

Starting in GitLab 14.0, SSH keys added to GitLab that have expired will be disabled by default. This is a change from the current behavior where expired SSH keys can still be used unless explicitly disabled by an administrator.

Administrators can still allow the use of expired keys in the same way as they can override expiration settings for Personal Access Tokens.

Planned removal date: June 22, 2021

Fuzz test jobs will fail with allow_failure if vulnerabilities are found

To make sure our fuzz testing jobs behave consistently with each other, as part of 14.0, all fuzz testing jobs will start failing if a job finds vulnerabilities. These jobs will have allow_failure=true set in them so you will get a warning but your pipeline as a whole will not fail if a vulnerability is found.

This is the current behavior for several of the fuzz scanners, such as the Go and C++ fuzz engines.

No action is required on your part to use this new behavior. If you are checking the results of a pipeline fuzz testing job as part of a script, consider if those scripts will need any updates.

Planned removal date: June 22, 2021

Git default branch name change

Every Git repository has an initial branch. It’s the first branch to be created automatically when you create a new repository. By default, this initial branch is named master. Future Git versions will change the default branch name in Git from master to main. In coordination with the Git project and the broader community, GitLab will be changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.

GitLab has already introduced changes that allow users to change the default branch name both at the instance-level (for self-managed users) and at the group-level (for both SaaS and self-managed users). We encourage users to make use of these features to set default branch names on new projects.

For more information, see the related epic and related blog post.

Planned removal date: June 22, 2021

GitLab OAuth implicit grant deprecation

GitLab is deprecating the OAuth 2 implicit grant flow as it has been removed for OAuth 2.1.

Beginning in 14.0, new applications will be unable to be created with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will no longer be supported in 14.4. Please migrate existing applications to other supported OAuth2 flows before release 14.4.

Planned removal date: June 22, 2021

GitLab Runner installation to ignore the skel directory

In GitLab Runner 14.0, the installation process will ignore the skel directory by default when creating the user home directory. Refer to issue #4845 for details.

Planned removal date: Jun 22, 2021

Helm v2 support

Helm v2 was officially deprecated in November of 2020, with the stable repository being de-listed from the Helm Hub shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the GitLab Helm chart, Helm v2 will no longer be supported.

Users of the chart should upgrade to Helm v3 to deploy GitLab 14.0 and above.

Planned removal date: June 22, 2021

Legacy Feature Flags Deprecation

Legacy Feature Flags became read-only in GitLab 13.4. Support for legacy Feature Flags will be removed in GitLab 14.0. You must migrate your legacy Feature Flags to the new version. You can do this by first taking a screenshot of the legacy flag for tracking, then delete the flag through the API or UI (you don’t need to alter the code), and finally create a new Feature Flag with the same name as the legacy flag you deleted. Also, make sure the strategies and environments match the deleted flag. We created a video tutorial to help with this migration.

Planned removal date: June 22, 2021

Limit projects returned in GET /groups/:id/

To improve performance, we will be limiting the number of projects returned from the GET /groups/:id/ API call to 100. A complete list of projects can still be retrieved by using the GET /groups/:id/projects API call.

Planned removal date: June 22nd, 2021

Make pwsh the default shell for newly-registered Windows Runners

In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.

Planned removal date: Jun 22, 2021

NFS for Git repository storage deprecated

With the general availability of Gitaly Cluster (introduced in GitaLab 13.0), we are deprecating support for NFS for Git repositories in GitLab 14.0.

We want to help you avoid purchasing expensive NFS appliances they won’t need, so invite customers currently using NFS for Git repositories to begin planning their migration.

To see our overall status, please review our Gitaly Cluster roadmap.

Planned removal date: June 22, 2021

One-click GitLab Managed Apps will be removed in GitLab 14.0

We are deprecating one-click install of GitLab Managed Apps. Although they made it very easy to get started with deploying to Kubernetes from GitLab, the overarching community feedback was that they were not flexible or customizable enough for real-world Kubernetes applications. Instead, our future direction will focus on installing apps on Kubernetes via GitLab CI/CD in order to provide a better balance between ease-of-use and expansive customization.

We plan to remove one-click Managed Apps completely in GitLab version 14.0. This will not affect how existing managed applications run inside your cluster, however, you’ll no longer have the ability to update modify those applications via the GitLab UI. We recommend cluster administrators plan to migrate any existing managed applications by reinstalling them either manually or via CI/CD. Migration instructions will be available in our documentation later.

Planned removal date: June 22, 2021

PostgreSQL 11 support

PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.

Starting in GitLab 13.7, all new installations default to version 12. From GitLab 13.8, single-node instances are automatically upgraded as well. If you aren’t ready to upgrade, you can opt-out of automatic upgrades.

Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.

Planned removal date: June 22, 2021

Removal of legacy fields from DAST report

As a part of the migration to a common report format for all of the Secure scanners in GitLab, DAST is making changes to the DAST JSON report. Certain legacy fields are being deprecated in 13.8 and will be completely removed in 14.0. These fields are @generated, @version, site, and spider. This should not affect any normal DAST operation, but does affect users who consume the JSON report in an automated way and use these fields. Anyone impacted by these changes who needs these fields for business reasons is encouraged to open a new GitLab issue and explain the need.

For more information, see the removal issue.

Planned removal date: Jun 22, 2021

In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.

Planned removal date: Jun 22, 2021

Remove AUTHORIZED_KEYS integration for SSH key lookup

Currently, GitLab has three different mechanisms by which it can look up the user attached to an SSH key when signing in. Those are:

  1. Integration via authorized_keys
  2. Fast lookup of SSH keys
  3. Lookup via SSH certificate

The first mechanism (integration via authorized keys) is vulnerable to both race conditions and out-of-order execution issues, making it hard to scale. Because of this it will be removed in GitLab 14.0. Refer to issue #212227 for details.

Planned removal date: June 22, 2021

Remove DAST default template stages

In GitLab 14.0, the stages defined in the current DAST.gitlab-ci.yml template will be removed to avoid the situation where the template overrides manual changes made by DAST users. This change is being made in response to customer issues where the stages in the template cause problems when used with customized DAST configurations. Because of this removal, gitlab-ci.yml configurations that do not specify a dast stage must be updated to include this stage.

In GitLab 13.8, the stages are deprecated and the changes to remove them from the template are included in the DAST.latest.gitlab-ci.yml template. Anyone can test and see if any changes are needed in their configuration files.

Planned removal date: Jun 22, 2021

Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag

In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.

Planned removal date: Jun 22, 2021

Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag

In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag. Refer to issue #27175 for details.

Planned removal date: Jun 22, 2021

Remove GLOBAL_DEFAULT_BRANCH_NAME feature flag

In GitLab release 14.0 we will remove the GLOBAL_DEFAULT_BRANCH_NAME feature flag. Refer to issue #325163 for details.

Planned removal date: June 22, 2021

Remove PUSH_RULES_SUPERSEDE_CODE_OWNERS feature flag

In GitLab release 14.0 we will remove the PUSH_RULES_SUPERSEDE_CODE_OWNERS feature flag. Refer to issue #262019 for details.

Planned removal date: June 22, 2021

Remove Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.

Planned removal date: Jun 22, 2021

Remove legacy DAST domain validation

Starting with GitLab 13.8, the current method of DAST Domain Validation for CI/CD scans is deprecated. In GitLab 14.0, the legacy DAST validation method will be removed. This method of domain validation only disallows scans if the DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED environment variable is set to true in the gitlab-ci.yml file, and a Gitlab-DAST-Permission header on the site is not set to allow. This two-step method created a situation in which users had to opt-in to using the variable before they could opt-out from using the header. For users concerned about protecting a site against a full, active scan, permission for a GitLab DAST scan can still be revoked by adding to any website a Gitlab-DAST-Permission header with a value of deny. This continues to block GitLab DAST scans attempted against any website that includes this HTTP header.

For more information, see the removal issue.

Planned removal date: Jun 22, 2021

Remove off peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.

Planned removal date: Jun 22, 2021

Remove success and failure for finished build metric conversion

In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.

Planned removal date: Jun 22, 2021

Remove translation from step_script to build_script in custom executor

In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the build_script stage will be replaced with step_script. Refer to issue #26426 for details.

Planned removal date: Jun 22, 2021

The default method of invoking Sidekiq will be sidekiq-cluster

In GitLab 13.0 we deprecated alternative ways of starting Sidekiq in favor of Sidekiq Cluster. Sidekiq Cluster provides additional options for managing Sidekiq queues and scaling.

This enables running multiple Sidekiq processes. Multiple Sidekiq processes allow a GitLab instance to continue to scale vertically, and are often a good first step prior to adding additional nodes. In addition, this will allow us to simplify support and improve maintainability for GitLab.com.

Directly invoking Sidekiq will no longer be supported as of GitLab 14.0.

For Omnibus installations, this should be entirely automatic. For Helm installations that set the queues option, see the documentation on upgrading.

Planned removal date: June 22, 2021

Ubuntu 16.04 support

Ubuntu 16.04 will reach end-of-life in April 2021, and no longer receive maintenance updates. We strongly recommend users to upgrade to a newer release, such as 20.04.

GitLab 13.12 will be the last release with Ubuntu 16.04 support.

Planned removal date: June 22, 2021

Unicorn will be removed in favor of Puma for GitLab self-managed

Unicorn support is deprecated and will be removed in GitLab 14.0. You must migrate to Puma before upgrading to GitLab 14.0.

Planned removal date: June 22, 2021

Update CI/CD templates to stop using hardcoded ‘master’

Our CI/CD templates will be updated so that they no longer use hard-coded references to a master branch. In 14.0, they will all be changed to use a CI/CD variable that points to your project’s configured default branch instead. If your CI/CD pipeline relies on our built-in templates, you may want to verify that this change will work with your current configuration. For example, if you have a master branch and a different default branch, the updates to the templates may cause changes to your pipeline behavior.

Planned removal date: June 22, 2021

Web Application Firewall (WAF)

GitLab’s Web Application Firewall (WAF) is deprecated in GitLab 13.6. As this is a breaking change, the WAF will be removed from the product on June 22, 2021 in GitLab 14.0. GitLab’s WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By deprecating and removing the WAF, GitLab will be able to focus its efforts on furthering other areas in the product where more value can be provided to users. Users who currently rely on GitLab’s WAF can continue to use the free and open source modsecurity project which is independent from GitLab. Additional details are available in the deprecation issue.

Planned removal date: June 22nd, 2021

Removals

Default DAST spider begin crawling at target URL

In GitLab 14.0, DAST will remove the current method of resetting the scan to the hostname when starting to spider. Previous to GitLab 14.0, the spider would not begin at the specified target path for the URL but would instead reset the URL to begin crawling at the host root. In GitLab 14.0, the default for the new variable DAST_SPIDER_START_AT_HOST will be changed to false to better support users’ intention of beginning spidering and scanning at the specified target URL, rather than the host root URL. In addition to starting to crawl the specified URL, this will have an added benefit that scans could take less time, if the specified path does not contain links to the entire site. This will enable easier scanning of smaller sections of an application, rather than the entire app being crawled at every scan.

Removal date: Jun 22, 2021

DevOps Adoption API

The first release of the DevOps Adoption report had a concept of “segments”. Segments were quickly removed from the report because they introduced an additional layer of complexity on top of “groups” and “projects”. Subsequent iterations of the DevOps Adoption report focus on comparing adoption across groups rather than segments. Any reference to “segments” will be removed from the GraphQL API in GitLab 14.0 and replaced with “groups”.

Removal date: June 22, 2021

Geo Foreign Data Wrapper settings removal in 14.0

As announced in GitLab 13.3, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:

  • geo_secondary['db_fdw']
  • geo_postgresql['fdw_external_user']
  • geo_postgresql['fdw_external_password']
  • gitlab-_rails['geo_migrated_local_files_clean_up_worker_cron']

Removal date: June 22, 2021

GraphQL API instanceStatisticsMeasurements field

In GitLab 13.6, the feature known as Instance Statistics was re-named Usage trends. To match that change, the GraphQL API field instanceStatisticsMeasurements has been deprecated in favor of usageTrendsMeasurements.

Removal date: June 22, 2021

Legacy storage removal in 14.0

As announced in GitLab 13.0 legacy storage is deprecated and will be removed in GitLab 14.0.

Before upgrading to GitLab 14.0 you must migrate fully to hashed storage.

Removal date: June 22, 2021

Migrate from SAST_DEFAULT_ANALYZERS to SAST_EXCLUDED_ANALYZERS

Until GitLab 13.9, if you wanted to avoid running one particular GitLab SAST analyzer, you needed to remove it from the long string of analyzers in the SAST.gitlab-ci.yml file and use that to set the SAST_DEFAULT_ANALYZERS variable in your project’s CI file. If you did this, it would exclude you from future new analyzers because this string hard codes the list of analyzers to execute. We avoid this problem by inverting this variable’s logic to exclude, rather than choose default analyzers. Beginning with 13.9, we migrated to SAST_EXCLUDED_ANALYZERS in our SAST.gitlab-ci.yml file. We encourage anyone who uses a customized SAST configuration in their project CI file to migrate to this new variable. If you have not overridden SAST_DEFAULT_ANALYZERS, no action is needed. The CI/CD variable SAST_DEFAULT_ANALYZERS will be removed in GitLab 14.0, which will release on June 22, 2021.

Removal date: June 22, 2021

Removals for License Compliance

In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. We have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, we are completely removing the License-Management CI template. Read about it in issue #216261 or this blog post.

Removal date: June 22, 2021

Remove SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets

With the release of SAST Custom Rulesets in GitLab 13.5 we allow greater flexibility in configuration options for our Go analyzer (GoSec). As a result we no longer plan to support our less flexible SAST_GOSEC_CONFIG analyzer setting. This variable was deprecated in GitLab 13.10. If you override or leverage SAST_GOSEC_CONFIG in your CI file, you will need to update your SAST CI configuration or pin to an older version of the GoSec analyzer. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will remove the old SAST_GOSEC_CONFIG variable in GitLab 14.0, releasing June 22, 2021.

Removal date: June 22, 2021

Remove secret_detection_default_branch job

To ensure Secret Detection was scanning both default branches and feature branches we introduced two separate secret detection CI jobs in our managed Secret-Detection.gitlab-ci.yml template. These two CI jobs, secret_detection_default_branch and secret_detection, created confusion and complexity in the CI rules logic. As part of this deprecation, we are moving the rule logic into the script section which will determine how the secret_detection job is run (historic, on a branch, commits, etc). If you override or maintain custom versions of SAST.gitlab-ci.yml or Secret-Detection.gitlab-ci.yml, you must update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to futureproof your CI templates. We will stop supporting the old secret_detection_default_branch job with GitLab 14.0, releasing June 22, 2021.

Removal date: June 22, 2021

WIP (work in progress) merge requests term deprecated

We renamed the WIP (work in progress) term for merge requests to “draft”, because it’s more inclusive and self-explanatory. The WIP term is now deprecated. We will support its use through the next major GitLab release (14.0), after which it will be removed.

Removal date: June 22, 2021

project-ref-sha repo archival route removal

Prior to GitLab 10.7 the method used to archive repositories returned an archive named project-ref-sha and a parent directory of the same name. This made the process of packaging releases more difficult as you had to know both the tag and the SHA.

GitLab 10.7 added the project-ref route which simplifies packaging by adding a route that returns an archive project-ref.

The old project-ref-sha has been removed in GitLab 13.11.

Removal date: April 22, 2021

Changelog

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

Installing

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

Updating

Check out our update page.

Questions?

We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans

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

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

  • Free: For small teams, personal projects, or GitLab trials with unlimited time.
  • 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 - GitLab.com: 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.
  • Premium: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Ultimate: Great with many CI/CD jobs. Every public project gets the features of Ultimate for free irrespective of their plan.

Cover image licensed under CC0

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 Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg