GitLab 14.0: Our annual major release
GitLab 14.0 is coming to GitLab.com. Along with the exciting new features, it also includes planned deprecations because it is the major version release for 2021. We try to minimize breaking changes, but some changes are needed to improve workflows, performance, scalability, and more.
These changes will go live on GitLab.com sometime between May 23 – June 22, through our daily deployments, leading up to the official release of 14.0 on June 22. Keep reading to learn more about these important changes.
GitLab 14.0 for self-managed users will also be released on June 22, read on for more information about deprecations and removals for self-managed instances.
Removed deprecated GraphQL fields
In accordance with our GraphQL deprecation process, the following fields, enum names, and mutation aliases that were deprecated on or before GitLab version 13.6 are permanently removed from our GraphQL API in 14.0.
Enums (each replaced by the upper-case version, such as
For mutation aliases, the concern name isn't as important as the name of the mutation itself. While you can't use this particular name anymore, we provide alternatives in our GraphQL documentation.
Name change of default branch in Git
Every Git repository has an initial branch, which is the first branch that is automatically generated when you create a new repository. By default, this initial branch is named
master. In Git version 2.31.0 – released March 15th, 2021 – the default Git branch name changed to
main. In coordination with the Git project and the broader community, GitLab is changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings, starting with GitLab 14.0.
For more information, see the related epic, documentation, and the Git mailing list discussion.
Deprecated legacy Gitaly cluster primary electors
Now that Praefect supports a
per_repository primary election strategy, GitLab 14.0 removes the legacy strategies deprecated in GitLab 13.12:
localelector is not supported in production, and should not affect production instances.
sqlelector is incompatible with the variable replication factor feature.
If you use the
sql primary electors, we recommend you update to the
per_repository election strategy as soon as possible. Read the migration documentation to learn more.
WIP merge requests renamed "draft merge requests"
WIP (work in progress) status for merge requests provide a clear signal to reviewers that the merge request in question is not ready to be merged. The WIP feature for merge requests has been renamed to "Draft", a more inclusive and self-explanatory term. "Draft" clearly communicates the merge request in question isn't ready for review, and makes no assumptions about the progress being made toward it. "Draft" also reduces the cognitive load for new users, non-English speakers, and anyone unfamiliar with the WIP acronym.
WIP merge requests were deprecated in favor of draft merge requests, and are removed entirely in GitLab 14.0.
Deprecated GitLab OAuth implicit grants
GitLab 14.0 deprecates the OAuth 2 implicit grant flow, as it has been removed for OAuth 2.1.
Beginning in GitLab 14.0, you can't create new applications with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will become unsupported in GitLab 14.4. Migrate existing applications to other supported OAuth2 flows before GitLab 14.4.
CI_PROJECT_CONFIG_PATH predefined project variable
CI_PROJECT_CONFIG_PATH predefined project variable is removed in favor of the
CI_CONFIG_PATH variable, which is functionally the same. If you are using
CI_PROJECT_CONFIG_PATH in your pipeline configurations update to use
Expired SSH keys disabled by default
Starting in GitLab 14.0, expired SSH keys added to GitLab are disabled by default. This changes the current behavior, which allows expired SSH keys to 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.
Changes to Code Quality Rubocop support
Currently, by default, the Code Quality feature doesn't provide support for Ruby 2.6+ if you're using the Code Quality template.
To better support the latest versions of Ruby, we are changing the default Rubocop version to add support for Ruby 2.4 through 3.0. Support for Ruby 2.1, 2.2, and 2.3 is dropped as a result of this change. To enable support for older versions, customize your configuration. Read the relevant issue "Default
codeclimate-rubocop engine does not support Ruby 2.6+"" to learn more about this change.
Renamed default Browser Performance Testing job
Browser Performance Testing currently runs in a job named
performance by default. This name can be confused with Load Performance Testing, introduced in GitLab 13.2. To make clear which job is running Browser Performance Testing, GitLab 14.0 renames the default job name from
browser_performance in the template. Read the relevant issue "Rename default Browser Performance Testing job" to learn more about this change.
Ruby version changing in
Ruby.gitlab-ci.yml template contains changes to better support new versions of Ruby. Previously, the
Ruby.gitlab-ci.yml file included Ruby 2.5. To better support the latest versions of Ruby, the template now uses
ruby:latest, which is currently Ruby 3.0. Read the ruby-lang.org release announcement to learn more about the changes to Ruby, and explore our relevant issue, "Updates Ruby version 2.5 to 3.0" to learn more about the change.
Removal of deprecated pipeline processing code
As part of improvements to CI/CD processing in GitLab and GitLab Runner, we deprecated some old pipeline processing methods in GitLab 13.3. GitLab 14.0 completely removes this unused code.
If you plan to upgrade from GitLab 13.2 or an older version 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 to GitLab 14.0. Alternatively, you can upgrade GitLab to a version between 13.3 and 13.12 first, then upgrade to 14.0.
GitLab Runner: Package installation ignores
skel directory during installation
In GitLab Runner 14.0, the installation process ignores the
skel directory by default when creating the user's home directory. For more details about this breaking change, read the deprecation issue.
GitLab Runner: PowerShell Core as default shell for newly registered Runners on Windows
Beginning in GitLab Runner 14.0, newly registered Windows Runners default to adding PowerShell Core (
pwsh) as the default shell in the
config.toml file, instead of the legacy Windows PowerShell (
GitLab Runner: Remove support for Windows Server 1909 image
Microsoft ended support for Windows Server version 1909 on May 11, 2021. In keeping with our support policy for Windows Server, GitLab 14.0 removes Windows 1909 support from GitLab Runner. If you are still using Windows Server 1909, then
docker-windows on GitLab Runner 14.0 or higher will no longer work. For additional details regarding this breaking change, read the deprecation issue.
Change default workflow to avoid duplicate pipelines in merge requests
Today, you can configure a pipeline in a way that accidentally triggers an extra pipeline. This often happens by creating a configuration that allows branch pipelines and merge requests pipelines to trigger simultaneously. When the pipeline is configured this way, pushing to a branch with an open merge request triggers two pipelines, when you only intended one.
In previous releases, you could use
workflow:rules with the
CI_OPEN_MERGE_REQUESTS variable to allow both pipeline types in one configuration, without triggering extra pipelines. In GitLab 14.0, this
workflow:rules becomes the default behavior in pipelines with no
If you don't want this new default behavior, you can add your own
workflow:rules to your pipeline configuration. This overrides the new default, and restores the original behavior. Pipelines already using
workflow:rules are unaffected. Explore the issue, "Make the workflow to avoid duplicate pipelines in merge requests the default configuration", where we made the change happen.
Renewed template for Auto DevOps: Stable Auto Deploy
GitLab 14.0 renews 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, meaning, unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the
v2 versions are not backward compatible, so 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.
Deprecated release description in the Tags API
GitLab 14.0 removes support for the release description in the Tags API. You can no longer add a release description when creating a new tag. You also can't create or update a release through the Tags API. You should migrate to the Releases API instead.
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 GitLab 14.0 removes. We recommend that you stop using
disk source configuration, since it is no longer supported and cannot be selected. Use
gitlab for an API-based configuration instead. To migrate away from the
disk source configuration, set
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.
Deprecated legacy feature flags
Legacy feature flags became read-only in GitLab 13.4, and GitLab 14.0 removes support for them. You must migrate your legacy feature flags to the new version, as described in the documentation. Watch the video tutorial below for help with the migration:
Empty container registries will have the cleanup policies turned off
The cleanup policy is a scheduled job you can use to remove or preserve tags from the Container Registry. In GitLab 14.0, we will make an update that will turn the cleanup policy feature off for projects that have no container images in their registry. Moving forward, a recurring job will regularly run to ensure that projects with no container images do not have the cleanup policy feature turned on.
This change significantly improves the performance and reliability of the feature and allows us to prioritize exciting usability features like a preview-run, as proposed in the issue, "Expiration policy dry-run and forced run".
If this change affects you, you can easily enable the feature again by following the steps in the documentation.
Removed one-click GitLab Managed Apps
GitLab 13.7 deprecated the one-click install of GitLab Managed Apps, and GitLab 14.0 removes them entirely. Although GitLab Managed Apps made it easy to start deploying to Kubernetes from GitLab, feedback from the community was that they were not flexible or customizable enough for real-world Kubernetes applications. Our new direction focuses on installing apps on Kubernetes with GitLab CI/CD to provide a better balance between ease-of-use and extensive customization.
This removal does not affect how existing managed applications run inside your cluster. However, you no longer can update or modify those applications in the GitLab UI. We recommend cluster administrators migrate any existing managed applications by reinstalling them either manually or via CI/CD. Migration instructions will be available in our documentation later.
Renewed template for Terraform
GitLab 14.0 renews the Terraform CI/CD template to the latest version. The new template is set up for the GitLab Managed Terraform state. It includes a dependency on the GitLab
terraform-images image to improve the user experience with GitLab's Infrastructure as Code features.
Since the current stable and latest templates are incompatible, and the latest template becomes the stable template GitLab 14.0, your Terraform pipeline might encounter an unexpected failure if you run a custom
Auto Build uses Cloud Native Buildpacks by default
In GitLab 14.0, Auto Build now defaults to Cloud Native Buildpacks instead of Herokuish when no
Dockerfile is present. Users depending on the
/bin/herokuish binary provided by Herokuish should either change their deployments to use
/cnb/lifecycle/launcher instead of
/bin/herokuish exec, or opt-out of using Cloud Native Buildpacks, by setting the CI variable
Removals for SAST and Secret Detection
This release removes or migrates several variables:
- Removes the SAST Analyzer variable
SAST_GOSEC_CONFIGin favor of custom rulesets for expanded configuration and consistency.
- Removes the global variable
SAST_ANALYZER_IMAGE_TAGin favor of analyzer-specific variables to provide more granular control of versioning analyzers.
- Migrates the variable
SAST_EXCLUDED_ANALYZERSfor better forward compatibility.
This release also removes the
secret_detection_default_branch job in our managed
Secret-Detection.gitlab-ci.yml template to reduce CI complexity.
If you override or maintain custom versions of
Secret-Detection.gitlab-ci.yml, update your CI templates. We strongly encourage you inherit and override our managed CI templates to future-proof your CI templates.
Removed the License-Management CI template
In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. GitLab 14.0 completely removes the License-Management CI template. We have been providing backward compatibility by warning users of the old template to switch. Read the change in the relevant issue #216261 or blog post.
Deprecations for Dependency Scanning
To exclude a DS analyzer previously 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. Now you should be able to migrate from
DS_EXCLUDED_ANALYZERS as described in the documentation. Read more about the change in relevant issue, the 13.9 release post, and the relevant blog post.
To prevent the Gemnasium analyzers to fetch the advisory database at runtime, you previously had to set the
GEMNASIUM_DB_UPDATE variable. But this is not documented properly and its naming is inconsistent with the equivalent
BUNDLER_AUDIT_UPDATE_DISABLED variable. You should migrate from
GEMNASIUM_UPDATE_DISABLED when it is available. Read about the change in the relevant issue.
DAST environment variable renaming and removal
GitLab 13.8 renamed multiple environment variables to support broader usage in different workflows. GitLab 14.0 permanently removes these variables, and they no longer work. If you use the old variables in your configuration it's time to update to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly:
DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIREDis removed, as the feature is being removed.
Web Application Firewall (WAF) removal
GitLab's Web Application Firewall (WAF) was deprecated in GitLab 13.6. GitLab 14.0 removes the WAF on June 22, 2021. 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 can focus on improving other areas in the product to provide more value to users.
If you currently rely on GitLab's WAF, we recommend you continue to use the free and open source ModSecurity project, which is independent from GitLab. More details are available in the deprecation issue.
Container Scanning Engine Clair removal
Prior to GitLab 14.0, GitLab used the open-source Clair engine for container scanning. Clair was deprecated in GitLab 13.9, and GitLab 14.0 replaces Clair with Trivy. If you use any GitLab 13.x release, you can continue to use Clair without making any changes to your CI files – however, GitLab will no longer update or maintain that scanning engine.
Beginning in the 14.0 release Trivy becomes the new default scanner and receives regular updates and the latest features. You should review their CI files in advance of the 14.0 release and follow these instructions to ensure your container scanning jobs continue to work. You can provide feedback and get additional details about the change to Trivy on our open deprecation issue.
Remove old Advanced Search migrations in GitLab 14.0 release
Advanced Search migrations is a feature that helps you update your Elasticsearch index in the background when a GitLab version upgrade introduces changes to indexes. Advanced Search migrations add complexity that requires us to support multiple code paths. It's important to reduce this complexity while keeping it safe.
GitLab 14.0 removes all migrations that were added before the 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 you may need to recreate your Advanced Search index. You can find more information about the process of deleting migrations in our Elasticsearch development documentation.
Enforce maximum attachment size on Project API uploads
Some people use the project API to upload large binaries to link in the Release pages. This API was originally intended only to share attachments in issues or merge requests, and should have been subject to the configured maximum attachment size (10 MB by default). GitLab 14.0 enforces the size limit, and uploads that exceed this limit now fail with a
413 Entity Too Large error. Files that already uploaded remain downloadable.
updated_at filter from Deployment API
Some users are pulling data from the
list project deployments API endpoint to populate a custom-built dashboard. There is no way to restrict the API results to display only the latest changes. To overcome this, you must retrieve all records, check them one-by-one, and process only the records updated after the latest
updated_at value in the last batch retrieved.
GitLab 14.0 changes this API to make this process more efficient and performant:
- Queries specifying the
updated_atfilter must set
Limit projects returned in
To improve performance, GitLab 14.0 limits the number of projects returned from the
GET /groups/:id/ API call to 100. You can still retrieve a complete list of projects with the
GET /groups/:id/projects API call.
trace parameter from
GitLab Runner was previously updated to change how it communicates with GitLab. Some internal code is no longer in use, and GitLab 14.0 deprecates this unused code. Make sure your GitLab Runner version matches your GitLab version to ensure consistent behavior.
Deprecate segments from 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 focuses on comparing adoption across groups rather than segments. GitLab 14.0 removes all references to "segments" in the GraphQL API and replaces them with "groups".
Cover image by PHOTOGRAPHER Silvia Brazzoduro on Unsplash
“Learn more about the features that will be deprecated in @GitLab 14.0” – Orit Golowinski
Click to tweet