May 22, 2021 - Mark Wood  
13.12

GitLab 13.12 released with On-Demand DAST and Deployment Frequency Chart

GitLab 13.12 released with On-Demand DAST, Deployment Frequency Chart, Visualization of Pipeline Job Dependencies and much more!

This month, we are excited to introduce usability and pipeline management improvements that strive to make your teams more productive, updates to make your deployments more secure, and insights to make your DevOps adoption more mature. These are just a few highlights from the 44 improvements in this release.

Helping you manage security before it manages you

To ensure your production environment is always secure, On-demand DAST scanning is now generally available for all GitLab Ultimate customers. These on-demand scans will allow you to scan an already deployed application or API in any of your configured environments outside of a CI/CD pipeline i.e., without requiring any code changes or merge requests to start a scan.

The Semgrep SAST analyzer for JavaScript, TypeScript, and Python is also generally available. Semgrep's flexible rule syntax is ideal for streamlining the GitLab Custom Rulesets feature for extending and modifying detection rules, a popular request from GitLab SAST customers. It also allows GitLab customers access to Semgrep's community rules. Thanks to the community contribution from @proletarius101, we are also extending the Mobile Application Security Testing to support .ipa (iOS) and .apk (Android) binary files, in addition to Xcode projects and Android manifest files that are already supported.

Many customers integrate their existing scanners into GitLab to benefit from a unified view. The Project Vulnerability Report now gives you the ability to filter by scanner and vendor, allowing you to filter scan results for only third-party scanners or for all scanners including those from GitLab.

Application Security is a key focus area for GitLab for this year and your feedback is important to us. As the preference of web application development shifts rapidly towards building JavaScript-heavy and single-page applications, we have identified a need for a purpose built tool that provides more application testing coverage than a traditional proxy based crawler. We are inviting GitLab Ultimate customers to a public beta for a new browser-based crawler for DAST which is expected to provide significantly better security testing coverage for these modern applications compared to our current proxy-based crawler.

Easier pipeline management for enhanced usability

Pipelines are at the heart of our customers' CI/CD success, and we want to make it easier to use for new and experienced users of GitLab. The pipeline editor will now come with a collapsible panel of guided instructions that will help new CI/CD users create their first pipeline in a breeze.

For experienced CI/CD users that require more flexibility in creating their pipelines, we are now supporting wildcards in the include: keyword that will help you break your .gitlab-ci.yml file into multiple smaller files to improve reusability and readability. We also introduced the ability to define variables within rules, giving you the flexibility to set pipeline variables when certain conditions are met. Defining complex pipelines means there could be dependencies between jobs. The pipeline graph now shows dependencies between jobs, which is helpful to visually track and understand the expected order in which the jobs will be run.

Insights to improve your DevOps maturity

You cannot fix what you cannot measure. In that spirit, we are continuing to natively support DORA4 metrics. We are happy to announce the introduction of a group-level deployment frequency chart, which will help you understand the efficiency of your deployments over time, find bottlenecks, and focus on improvement areas that span across your projects and teams.

Value stream analytics help you identify inefficiencies and identify the root cause of those inefficiencies in your workflow. In 13.12, we have introduced pagination and sorting of workflow items, which allows you to easily visualize and sort items in a specific stage to pinpoint bottlenecks. The Days to Completion chart has been updated to show the average time to completion, which helps identify meaningful trends over time.

In this release, thanks to the community contribution from @leetickett, we introduced the ability to view a time tracking report within an individual issue or merge request to provide visibility into how much time each contributor spent.

For many of our customers, merge requests are the central space for collaboration. We have introduced the ability to see code quality violations and screenshots of failed tests within the merge request to give you necessary context as a part of your normal workflow within GitLab.

And so much more!

We continue to invest in improving the product usability in every release. Some of our favorite quality of life improvements in 13.12 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 14.0 release kickoff video.

Join us for REMOTE by GitLab to explore the future of work, culture, and inclusion.

GitLab MVP badge

This month's Most Valuable Person (MVP) is Lee Tickett

Lee did an excellent job iterating on our existing time tracking functionality by adding a time tracking report feature! This allows you to easily see who has spent time on an issue, and even allows you to add notes!

This contribution is a significant step forward as it not only allows you to view who has spent how much time on an issue, but also allows you to see the total time spent by all contributors. There is even an option to add notes when you log time and view them within the report.

Lee has also contributed two additional merge requests to improve the GraphQL API, one to expose merge request timelogs, and one expand the GraphQL query to find merge requests.

Thank you for all of your amazing work Lee! 🙌

Key features released in GitLab 13.12


On-demand DAST GA launch

After months of work, we are pleased to announce that our on-demand DAST scanning has reached a General Availability (GA) maturity level. It is ready for usage by anyone who needs to scan an already-deployed application or API outside of a CI/CD pipeline job. With the 13.11 release, we added to on-demand DAST Site profiles the ability to specify authentication information, exclude URLs, add additional request headers, and switch between scanning web applications and APIs. This is in addition to the ability to save scans for quick reusability that was added in 13.9, and the ability to select the branch that a scan is associated with that was added in 13.10. We believe this feature set meets the needs of a majority of GitLab customers.

As we continue to add features, such as scan scheduling, we expect on-demand DAST scanning to cover an ever-increasing range of use cases. As always, we would love as much feedback about these features as possible. Please let us know how things are working for you by leaving a comment in issue 327396.

On-demand DAST GA launch

Useful GitLab CI/CD information in the pipeline editor

Creating your first GitLab CI/CD pipeline can be difficult, especially for those new to CI/CD. You might spend time switching back and forth between documentation and GitLab to get your first pipeline configured. In this release we’ve added a drawer with useful information to the pipeline editor to help guide you through the steps of writing your first pipeline.

Useful GitLab CI/CD information in the pipeline editor

Support wildcards when including YAML CI/CD configuration files

The includes: keyword for CI/CD pipelines lets you break one long .gitlab-ci.yml file into multiple smaller files to increase readability. It also makes it easier to reuse configuration in multiple places. Frequently there are multiple files included into a single pipeline, and they all might be stored in the same place. In this release, we add support to use the * wildcard with the local includes: keyword. You can now make your includes: sections more dynamic, less verbose, and easier to read, check out how we are dogfooding it in GitLab.

Support wildcards when including YAML CI/CD configuration files

Show job dependencies in the pipeline graph

The full pipeline graph provides a visual representation of all the jobs in your CI/CD pipeline, grouped by stage. This visualization helps you track the progress of your jobs and sets expectations for the order in which jobs will execute.

The introduction of the needs keyword let you create a directed acyclic graph that lets jobs start running earlier than they would if they were configured solely by stage. However, this creates ambiguity when looking at the pipeline graph, as its harder to tell in what order you could expect jobs to run.

In this release, you now have the ability to view pipelines by job dependencies when the job order reflects the needs: relationships between jobs. We’ve also added links between jobs to see exactly which jobs need to complete before a particular job can start. It will be much easier for you to track and understand job dependencies and expected run order when using the needs: keyword.


Failed test screenshots in test report

GitLab makes it easy for teams to set up end-to-end testing with automation tools like Selenium that capture screenshots of failed tests as artifacts. This is great until you have to sort through a huge archive of screenshots looking for the specific one you need to debug a failing test. Eventually, you may give up due to frustration and just re-run the test locally to try and figure out the source of the issue instead of wasting more time.

Now, you can link directly to the captured screenshot from the details screen in the Unit Test report on the pipeline page. This lets you quickly review the captured screenshot alongside the stack trace to identify what failed as fast as possible.

Failed test screenshots in test report

Code quality violation notices in MR diffs

During code reviews, you may have wanted to highlight Code Quality violations and how to resolve them. Previously, this involved having a browser window open to see the violations on the Merge Request summary and another window reviewing the changes in the MR or your IDE. You may have found switching between them too difficult and given up.

Now, you can see if the file you are reviewing has new code quality violations that are part of the changes right in the Merge Request diff view. This gives you the necessary context to suggest a fix as part of your normal workflow within GitLab without having to keep additional windows open and context switch back and forth between them.

Code quality violation notices in MR diffs

Group-level deployment frequency CI/CD chart

As part of our efforts to natively support DORA4 metrics in GitLab, the group-level deployment frequency chart is now available. This chart will show the aggregated deployment frequency metrics for all the projects that are part of the group, and allow you to get a full picture of the deployment frequency across multiple projects and teams, so that you can comprehend their efficiency more accurately. Monitoring deployment frequency helps you understand the efficiency of your deployments over time, find bottlenecks, and focus on improvement areas that span across your projects and teams.

Group-level deployment frequency CI/CD chart

Other improvements in GitLab 13.12

Enforce delayed project removal for all subgroups

Group owners can now enable and enforce delayed project removal for all subgroups and projects in their group. Delayed project removal protects your data by placing deleted projects in a read-only state after deletion and can be restored, if required. We plan to expand our settings model and allow more settings to be inherited and enforced in subgroups and projects in future milestones. Our new settings management model gives group owners a way to ensure that their subgroups and projects settings adhere to their organization’s security and compliance needs.

Enforce delayed project removal for all subgroups

Users’ group counts now displayed in Admin Area

The user list in the Admin Area now shows the total number of groups a given user has access to. The group count is a sum of both group and subgroup membership.

This is incredibly valuable, because you can easily see how much access users have and quickly identify when action is needed. For example, you might use this information to ensure that deactivated accounts no longer have access to any projects or groups in GitLab.

Users' group counts now displayed in Admin Area

View average time to complete workflow items

The Days to Completion chart in Value Stream Analytics previously showed the sum of days it took to complete all workflow items that were finished on a specific day. If an unusually high number of items was completed on the same day, the chart would show a high number for that day, which isn’t particularly meaningful.

The chart now shows the average time to completion instead, which highlights meaningful trends over time.

View average time to complete workflow items

Time tracking reports for issues and merge requests

Project members can record time spent on an issue or merge request via the /spend quick action, but it hasn’t been easy to understand how much time each person contributed. As a step toward better visibility of time reports in projects and groups, you can now view a time report in an individual issue or merge request. After time is spent against an issue, select the Time tracking report on the sidebar to view a list of all time spent entries for that issue or merge request. Thanks @leetickett for the contribution!

Time tracking reports for issues and merge requests

Lock latest pipeline artifact to prevent deletion

GitLab now automatically locks the latest artifact produced from a successful pipeline on any active branch, merge request, or tag to prevent it from being deleted based on expiration if it is still the most recent artifact.

This makes it easier to set a more aggressive expiration policy to clean up older artifacts, helps reduce disk space consumption, and ensures you have always got a copy of the latest artifact from your pipeline.

Pipeline artifacts, such as those used by the test coverage visualization feature, are not explicitly managed by the .gitlab-ci.yml definitions.

Support variables in CI/CD pipeline ‘workflow:rules’

Previously, the rules keyword was limited in scope and only determined if a job should be included or excluded from pipelines. In 13.8, we added the ability to use the variables keyword with rules to set variable values in a job based on which rule matched. In this release we’ve extended this ability to workflow: rules, so you can set variable values for the whole pipeline if certain conditions match. This helps you make your pipelines even more flexible.

Support variables in CI/CD pipeline 'workflow:rules'

Delete associated package files via API

You use the GitLab Package Registry to publish, install, and share your dependencies. You may do this using a variety of package manager formats, such as Maven or npm. If you do this as part of your CI workflow, you may publish many packages to your registry. When you publish a dependency, it generates several files including the package archive.

Prior to GitLab 13.12, GitLab didn’t provide a way to delete the files from a package. You could only delete the package itself. These extra files can clutter the user interface or result in someone installing an incorrect or outdated dependency.

In GitLab 13.12, you can now use the Packages API to delete files related to a given package, as well as the package itself. You can easily integrate this new endpoint into your CI workflow and start removing old, unused files. To give you another option for managing your registry, future releases will add the ability to delete such files through the user interface.

Filter Project Vulnerability Report by vendor name

GitLab strives to play well with others and security is no exception. We provide many security scanners as part of our Secure offering. We also encourage 3rd party vendors to integrate their scanning tools using our open API and data interchange formats. A benefit of using GitLab is managing vulnerabilities from multiple scanners in a unified experience. While you were already able to filter by scanner type (SAST, DAST), it wasn’t possible to drill down by the tool provider.

You now have even more granularity when managing vulnerabilities with the new ability to filter by scanner and vendor. You can look at all results across a single vendor’s scanners or gain confidence in findings from one scan type (e.g. SAST) that are confirmed by both GitLab and the 3rd party tool. The new filtering capability is available now in Project Vulnerability Reports.

Filter Project Vulnerability Report by vendor name

New browser-based crawler for DAST in open beta

Starting in 13.12, we are extremely excited to announce the beta release of our new browser-based crawler. Since we are in the beta phase, we are actively seeking DAST users who will enable the new crawler and give us feedback. This new crawler is specifically designed to provide better application testing coverage by finding more pages on a JavaScript-heavy app that might be hidden from a traditional proxy-based crawler. As websites and applications continue to be more and more JavaScript-heavy, we have seen the need for a new generation of tools that are purpose-built to address the needs of JavaScript-heavy and single-page applications. This is our first step in the journey to provide better crawl and test coverage for these modern applications.

In our benchmark testing, our browser-based crawler has shown a significant improvement in crawl coverage from our current proxy-based crawler. We want feedback from usage on real-world applications to validate that the new crawler is able to crawl a majority of pages for a majority of apps. The process for enabling this new crawler is documented at DAST browser-based crawler.

Any and all feedback is welcomed and encouraged, as are bug reports. Feel free to comment in issue 327394 or create a new issue and assign it to @derekferguson. We look forward to bringing this feature to GA in the next few months and providing better DAST coverage for modern applications.

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.12. These updates bring additional coverage, bug fixes, and improvements.

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.

Filter active deploy tokens

Before this milestone, the Deploy Tokens API endpoints for listing tokens would return all database stored entries, including revoked and expired tokens, without a way to filter the list. Now we have added the ability to filter only active tokens from the REST API. A huge thanks to Devin Christensen for a great community contribution!

New Gatsby CI Pages template

The previous Pages template for Gatsby would not work out of the box. You needed to manually fix your pipelines after using the predefined template. In this milestone, we have provided a new template for you to use that results in a green pipeline upon first run. Thank you Takuya Noguchi for this great contribution that will help additional members of the GitLab wider community to get started with Pages.

Elastic Stack cluster integration

Previously, to take full advantage of Gitlab Log Explorer, you had to install the Elastic stack via GitLab Managed Apps. This was problematic because managing and operating the Elastic Stack is important and not something you wished to outsource to GitLab.

With this release, you can integrate your existing Elastic Stack with GitLab. Whilst maintaining control, you can still take advantage of the features offered by GitLab Log Explorer.

Create incidents via API

The most effective incident management tools enable you to create incidents automatically from different sources. To create incidents automatically, you can integrate your proprietary systems with GitLab via API. GitLab 13.12 introduces the issue_type attribute to the GitLab REST API and the type field to the GitLab GraphQL API. When creating issues with these APIs, you can create incidents by setting issue_type to incident (REST API), or by setting type to INCIDENT (GraphQL API).

Geo replicates LFS files with self-service framework

Although Geo already replicates LFS files, moving this functionality to use the Geo self-service framework improves maintainability and performance of LFS file replication. This update will allow us to delete around 200 of lines of code and more easily add support for verification in an upcoming release. LFS file replication and deletion events will also be triggered sooner (up to a minute in some cases). To learn more about the Geo self-service framework, read this blog post about how we are closing the gap on replicating everything in Geo.

Geo support for tracking database high-availability

Geo secondary sites use a separate PostgreSQL database as a tracking database to keep track of replication status and automatically recover from potential replication issues. Without the tracking database, Geo cannot replicate data to another site. Geo now supports setting up a separate, highly-available PostgreSQL cluster for Geo’s tracking database. This configuration is important when a secondary site is used as part of a disaster recovery strategy because it ensures that replication isn’t impacted even when a single PostgreSQL node running the tracking database fails.

GitLab chart improvements

  • Users were restricted to using the standard 80/443 port to expose NGINX to the LoadBalancer. However, the new nginx-ingress chart now gives users the ability to set their LoadBalancer service ports to a custom port. You can view the NGINX site configuration docs to learn more.
  • We have upgraded to PostgreSQL 13 client libraries. This allows us to support backup/restore to PostgreSQL 13, while still retaining support for PostgreSQL 12 and PostgreSQL 11. This has no impact on the version of PostgreSQL we are running in the chart.

Obfuscate Elasticsearch password in Admin UI

With the Elasticsearch integration, GitLab administrators could only configure a password-protected Elasticsearch server by using the URL with the format http(s)://<username>:<password>@<elastic_host>:<elastic_port>/. However, the password was displayed in plain text in the GitLab admin UI. Feedback given by our users showed us that this can be a potential liability as not all GitLab instance admins should be able to see that password.

With this release, we provide separate input fields for the Elasticsearch username and password, and the password is obfuscated so that users can’t see the characters in plain text.

Obfuscate Elasticsearch password in Admin UI

Improvements to the deployment metrics in Value Stream Analytics

We improved the Deploys and Deployment Frequency metrics in group-level Value Stream Analytics. These metrics now consider only deployments to environments classified as production tier instead of all deployments. The metrics now provide more value, because often deployments to non-production environments are not relevant.

Also, these metrics are now calculated based on the time the deployment finished, instead of the time it was created. This brings improved accuracy of the data in a given time frame.

Improvements to the deployment metrics in Value Stream Analytics

View and sort stage items in a value stream

Previously, Value Stream Analytics only displayed the 20 newest workflow items for each stage in a value stream. This update adds pagination and sorting for workflow items.

You can now view all the items in each stage of your value stream and sort by time spent in a stage to more easily pinpoint bottlenecks in the software development lifecycle. For example, if code changes have been taking longer to merge, sort items in the Code stage to identify the slowest items and investigate possible causes.

View and sort stage items in a value stream

View the number of workflow items in a value stream stage

Value stream analytics shows the median time that workflow items took to complete a stage in a value stream, as well as a list of the items that completed the stage. This release adds an item count so you can easily see how many workflow items completed the stage and were used to calculate the median value.

View the number of workflow items in a value stream stage

GitLab Runner 13.12

We’re also releasing GitLab Runner 13.12 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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Pipeline status widget in the pipeline editor

Previously, after committing changes using the pipeline editor, you had to navigate to a different page to know the real time status of your pipeline. In this release, we added a pipeline status widget to the pipeline editor so that you can monitor the status of your pipeline without leaving the comfort of the editor.

Pipeline status widget in the pipeline editor

Allow or prevent duplicate generic package uploads

You can use the GitLab Package Registry to publish and download your project’s generic packages. By default, you can publish the same package name and version multiple times.

However, many of you have expressed that you want to prevent duplicate uploads, especially for releases. GitLab 13.12 expands the group setting for the Package Registry to allow or prevent duplicate uploads.

You can adjust this setting by using the GitLab API, or from Settings > Packages & Registries in the application. The coming milestones will continue to expand this setting for each package manager format. Please follow along in the epic or consider contributing a change!

Configuration tool for Secret Detection

Following in the footsteps of the GitLab SAST configuration tool we are adding support for Secret Detection on the Security Configuration page. We believe that security is a team effort and this configuration experience makes it easier for non-CI experts to get started with GitLab Secret Detection. The tool helps a user create a merge request to enable Secret Detection scanning while leveraging best configuration practices like using the GitLab-managed SAST.gitlab-ci.yml template. The Configuration tool can create a new .gitlab-ci.yml file if one does not exist or update existing simple GitLab CI files, allowing the tool to be used with projects that already have GitLab CI setup.

Configuration tool for Secret Detection

Mobile application binary scanning support

Since GitLab 13.6, we’ve offered SAST for Android and iOS mobile projects. Initially our Mobile App SAST supported the automatic detection of Xcode projects and Android manifest files. With this release and contribution from community contributor @proletarius101, GitLab SAST now also supports the automatic detection of .ipa (iOS) and .apk (Android) binary files enabling the security scanning of fully built mobile application artifacts. This offers mobile teams more flexibility with how they build and scan their mobile projects with GitLab SAST for security vulnerabilities. Please note that mobile application scanning is still an experimental feature and requires enabling the experimental flag in your CI template. We will make the mobile application scanner generally available without this flag in the near future.

Semgrep SAST Analyzer for JavaScript, TypeScript, and Python

In GitLab 13.11 we announced an experimental release of Semgrep, a new SAST analyzer for JavaScript, TypeScript, and Python. This transition has been developed in partnership with r2c, the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our experimental analyzer, we’re ready to start the transition to Semgrep.

With 13.12, we’re updating our managed SAST.gitlab-ci.yml CI template to automatically run this new analyzer alongside our existing JavaScript and TypeScript analyzer, ESlint. In a future release we will fully disable ESLint, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our SAST.gitlab-ci.yml, you don’t need to do anything to start benefiting from the Semgrep analyzer, however if you override or manage your own SAST CI configuration, you should update your CI configuration.

Both GitLab and r2c are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.

Deleting deploy keys will inform the user if in use

In this release, we have added an additional safety measure to warn users that a deploy key is in use before deleting the key. This will help prevent accidentally breaking workflows.

Deleting deploy keys will inform the user if in use

Migrate GitLab Pages in the background

In preparation for moving GitLab Pages to the new ZIP-storage architecture in 14.0, we introduced an automatic background migration in 13.11. This background migration converted existing sites to the new storage format and run at a very slow speed to avoid having a significantly negative impact on the performance of your instance. In GitLab 13.12, we will add the option to run the same migration with greater speed. You can also run the migration manually. This will allow you to verify the migration result, identify any migration errors, and fix them.

Since GitLab 13.2, you’ve been able to use the release: keyword, in conjunction with the release-cli, to create a release. The release: keyword has now been extended to include support for asset links so that you can create releases and attach files to them in a single .gitlab-ci.yml release job.

release: keyword supports asset links

Take ownership of existing GitLab Managed Applications

As previously announced, one-click GitLab Managed Applications were deprecated in GitLab 13.9 and will be definitively removed from GitLab in version 14.0, scheduled for June 22nd. Follow the documentation to learn how to take ownership of your applications and continue using them normally.

Warn administrator when removing an on-call user

Being on-call is a critical function. It affects the on-call schedule when an administrator removes an on-call user from a project, a group, or the GitLab instance. Administrators are now warned before executing such a removal.

Warn administrator when removing an on-call user

Geo support for PostgreSQL high availability in Beta

Patroni is a solution for PostgreSQL high availability which also allows the configuration of a highly-available PostgreSQL standby cluster on a Geo secondary. This configuration is important when a secondary is used as part of a disaster recovery strategy because it allows systems administrators to mirror the number of database nodes on the primary and secondary. This means that after a failover, no additional database nodes need to be provisioned to regain high availability.

Geo now provides beta-level support for highly available PostgreSQL configurations using Patroni. We’ve improved upgrades to a Patroni standby cluster, implemented automatic recovery from leader changes on the primary, addressed initial setup issues, and fixed a number of bugs.

Geo verifies replicated Terraform state files

Geo automatically verifies the data integrity of replicated Terraform state files. 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.

Instance-level Federated Learning of Cohorts (FLoC) opt-in

Federated Learning of Cohorts (FLoC) is a new type of web tracking, intended to replace the use of third-party cookies. It does this by grouping users into cohorts based on their browsing history, for the primary purpose of interest-based advertising. FLoC is being activated in the Chrome browser in some regions.

With GitLab 13.12, FLoC will not incorporate GitLab browsing activity by default. If an instance administrator would like their users’ GitLab instance usage to contribute to FLoC, they can re-enable in instance settings.

Omnibus improvements

Bug Fixes

Some of the notable bug fixes in 13.12 are:

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.12, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.12 are:

Usability Improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 13.12, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 13.12:

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 backward 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_PROJECT_CONFIG_PATH will be removed in GitLab 14.0

In GitLab 14.0, the CI_PROJECT_CONFIG_PATH pre-defined project variable will be removed in favor of CI_CONFIG_PATH, which is functionally the same.

If you are using CI_PROJECT_CONFIG_PATH in your pipeline configurations, please update them to use CI_CONFIG_PATH instead.

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 updated 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 re-enable 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 renamed 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: June 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 CI/CD template method for GitLab Managed Applications

In GitLab 13.12, we are deprecating the CI/CD template installation method for GitLab Managed Apps. Therefore, as of today, it will no longer be improved by GitLab. The CI/CD template is scheduled to be definitively removed in GitLab 15.0.

As the other installation method for GitLab Managed Apps, called “one-click install” had been deprecated in 13.9, the entire feature is now deprecated.

As a replacement, to foster easier and faster installation and configuration of applications in your cluster, we will release a project template in GitLab 14.0 that improves the functionalities and eliminates the configuration restrictions that we had with the CI/CD template method. The new project template will allow users to extend the setup with other applications and own them entirely. The cluster management project integrations remains unchanged.

Planned removal date: June 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 legacy Gitaly Cluster primary electors

Now that Praefect supports a per_repository primary election strategy to elect a primary for each repository, we will be deprecating the legacy strategies in GitLab 13.12 so we can remove them in GitLab 14.0.

  • The local elector is not supported in production, so should not impact production instances.
  • The sql elector is incompatible with the variable replication factor functionality.

For anyone using local or sql primary electors, we recommend you update to the per_repository election strategy as soon as possible. See the migration documentation.

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 to 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 the 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 announced plan to pin the Static Analysis tools.

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 deprecations coming up 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 fetching the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE 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

Drop updated_at filter from Deployment API

If you are pulling data from the project deployments API endpoint to populate a custom-built dashboard in GitLab, you may have noticed that there is no way to restrict the API results to display only the latest changes. To overcome this, you had to retrieve all records, check the results one-by-one, and process only the records updated after the latest updated_at value in the last batch retrieved. In order to make this process more efficient and performant, this API will change in GitLab 14.0. The updated_after and updated_before parameters will be replaced by finished_after and finished_before parameters. This will enable users to more efficiently choose the deployments they are interested in retrieving.

Planned removal date: June 22, 2021

Dropping support for SAST scanning of Go projects without Go modules enabled

As part of maintaining our Go SAST analyzer GoSec, we need to upgrade to Go 1.16. This means that we will no longer scan projects that do not have Go modules enabled, which drops support for Go versions prior to 1.11. If you require scanning of older Go projects you can override our managed CI templates and pin the Go analyzer to v2.20.0.

Planned removal date: June 22, 2021

Expired SSH keys disabled by default

Starting in GitLab 14.0, expired SSH keys added to GitLab will be disabled by default. This helps to make your GitLab instance more secure. Currently, expired SSH keys added to GitLab are enabled by default and can be used unless explicitly disabled by an administrator.

This also will affect you if you use expired SSH keys on GitLab.com. If your keys are expired or will be expired by the time of this release, you need to update the key and any projects using them. Our documentation on SSH keys has steps on how to create a new SSH key you may find helpful.

Administrators can still allow the use of expired keys similar to how they can override expiration settings for Personal Access Tokens.

Planned removal date: June 22, 2021

External Pipeline Validation Service response code changes

For self-managed instances using the experimental external pipeline validation service, the range of error codes GitLab accepts will be reduced. Currently, pipelines are invalidated when the validation service returns a response code from 400 to 499. In GitLab 14.0 and later, pipelines will be invalidated for the 406 response code only.

Planned removal date: June 22, 2021

Free tier scheduled pipeline limitation 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, we are limiting the frequency of scheduled pipelines for free users to 10 pipeline per day per project. Premium and Ultimate users will not be affected by this change.

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

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']

Planned removal date: June 22, 2021

Git default branch name change

Every Git repository has an initial branch, which is named master by default. It’s the first branch to be created automatically when you create a new repository. 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.

  • The change for GitLab.com will occur on May 24th, 2021.
  • The change for self-managed GitLab will ship with GitLab 14.0 on June 22nd, 2021.

GitLab has already introduced changes that allow you 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 you 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: June 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

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.

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

Planned removal date: June 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 you won’t need, so invite customers currently using NFS for Git repositories to begin planning their migration.

We are pleased to provide documentation on Migrating to Gitaly Cluster.

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

For users of alerts on managed Prometheus, in GitLab version 14.0, we will also remove the ability to set up / modify alerts from the GitLab UI. This change is necessary because the existing solution will no longer function once managed Prometheus is removed.

Planned removal date: June 22, 2021

OpenSUSE Leap 15.1

Support for OpenSUSE Leap 15.1 is being deprecated. Support for 15.1 will be dropped in 14.0. We are now providing support for openSUSE Leap 15.2 packages.

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 PostgreSQL with Patroni. Geo secondaries can then be updated and re-synchronized.

Planned removal date: June 22, 2021

Redis 4 deprecation

In GitLab 12.7, the Redis version was updated to Redis 5. Redis 4 has reached end of life and will no longer be supported as of GitLab 14.0. If you are using your own Redis 4.x instance, you should upgrade it to Redis 5.x or 6.x before GitLab 14.0 is released.

Planned removal date: June 22, 2021

Removal of deprecated ‘trace’ parameter from ‘jobs’ API endpoint

GitLab Runner was updated in GitLab 13.4 to internally stop passing the trace parameter to the /api/jobs/:id endpoint. In GitLab 14.0 we will deprecate the trace parameter entirely for all other requests of this endpoint. Make sure your GitLab Runner version matches your GitLab version to ensure consistent behavior.

Planned removal date: June 22, 2021

Removal of deprecated pipeline processing code

We are constantly working on improvements to CI/CD processing in GitLab and GitLab Runner. As part of this work, in GitLab 13.3 we deprecated some old pipeline processing methods. In GitLab 14.0, we will completely remove this code that is no longer in use.

If you plan to upgrade from GitLab 13.2 or older directly to 14.0, you should not have any pipelines running when you upgrade, as they might report the wrong pipeline status when the upgrade completes. We recommend shutting down GitLab and waiting for all pipelines on runners to complete, then upgrading GitLab to 14.0. Alternatively, you can upgrade GitLab to a version between 13.3 and 13.12 first, then upgrade to 14.0.

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 were 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: June 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: 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 were 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: June 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: June 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: 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.

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: June 22, 2021

Remove legacy DAST domain validation

As of GitLab 13.8, the current method of DAST Domain Validation for CI/CD scans was 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: June 22, 2021

Remove off peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, 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: June 22, 2021

Remove old Advanced Search migrations in GitLab 14.0 release

Advanced Search migrations is a feature that helps users update their Elasticsearch index in the background when changes are introduced to the indexes when upgrading their GitLab version. Advanced Search migration adds complexity that requires us to support multiple code paths. It’s important to reduce this complexity while keeping it safe. In GitLab 14.0, we will remove all migrations that were added prior to GitLab 13.12 release. ** Instances Running GitLab 13.11 or under must be upgraded to GitLab 13.12 before upgrading to GitLab 14.0**, otherwise it may require recreating your Advanced Search index. You can find more information about the process of deleting migrations in our Elasticsearch development documentation.

Planned removal date: June 22, 2021

Remove redundant key/value pair from the payload of DORA metrics API

The deployment frequency project level API endpoint has been deprecated in favor of the DORA 4 API, which consolidates all the metrics under one API with the specific metric as a required field. As a result, the timestamp field, which doesn’t allow adding future extensions and causes performance issues, will be removed. An example response would be { "2021-03-01": 3, "date": "2021-03-01", "value": 3 }. The first key/value ("2021-03-01": 3) will be removed and replaced by the last two ("date": "2021-03-01", "value": 3).

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

Planned removal date: June 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: June 22, 2021

Remove support for Windows Server 1903 image

In 14.0, we will remove support for Windows Server 1903 as Microsoft ended support for this version on 2020-08-12. Refer to issue #27551 for details.

Planned removal date: June 22, 2021

Remove support for Windows Server 1909 image from GitLab Runner

Microsoft’s end of support date for Windows Server version 1909 end was 2021-05-11. In keeping with our support policy for Windows Server, we will remove Windows 1909 support from GitLab Runner. If you are still using Windows Server 1909, then docker-windows on GitLab Runner 14.0+ will no longer work. Refer to issue #27899 for details.

Planned removal date: June 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: June 22, 2021

Renewal of the stable Auto Deploy template in Auto DevOps

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

Ruby version changing in Ruby.gitlab-ci.yml

Currently, by default, the Ruby.gitlab-ci.yml file includes Ruby 2.5.

To better support the latest versions of Ruby, the template is being changed to use ruby:latest which is currently 3.0. To better understand the changes in Ruby 3.0, please reference the ruby-lang.org release announcement.

Relevant Issue: Updates ruby version 2.5 to 3.0

Planned removal date: June 22, 2021

Ubuntu 16.04 support

Ubuntu 16.04 reached end-of-life in April 2021, and no longer receives 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

Support for Unicorn is deprecated and will be removed in GitLab 14.0 in favor of Puma. Puma has a multi-threaded architecture which uses less memory than a multi-process application server like Unicorn. On GitLab.com, we saw a 40% reduction in memory consumption by using Puma. 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 to no longer use hard-coded references to a master branch. In 14.0, they will all be changed to use a 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

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: June 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

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 global_default_branch_name feature flag

In preparation to change the default Git branch name from master to main, we have removed the global_default_branch_name feature flag. Refer to issue #325163 for details.

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.

Removal date: June 22, 2021

WIP (work in progress) merge requests removal

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

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