Note: This post was updated on May 20, 2022, to reflect the release of GitLab 15.0.
GitLab 15.0 has arrived! Along with the exciting new features, it also includes planned removals of previously deprecated features. Some of these removals are breaking changes, because this release is a major version release. We try to minimize such breaking changes but sometimes they are needed to improve workflows, performance, scalability, and more. Please keep reading to learn more about these important changes.
To see all removals in 15.0, visit GitLab Docs. Jump to the list of breaking changes in each stage by clicking below:
Manage
Audit events for repository push events
Announced in 14.3
Audit events for repository events are removed as of GitLab 15.0.
Audit events for repository events were always disabled by default and had to be manually enabled with a feature flag. Enabling them could slow down GitLab instances by generating too many events. Therefore, they are removed.
Please note that we will add high-volume audit events in the future as part of streaming audit events. An example of this is how we will send Git fetch actions as a streaming audit event. If you would be interested in seeing repository push events or some other action as a streaming audit event, please reach out to us!
External status check API breaking changes
Announced in 14.8
The external status check API was originally implemented to support pass-by-default requests to mark a status check as passing. Pass-by-default requests are now removed. Specifically, the following are removed:
- Requests that do not contain the
statusfield. - Requests that have the
statusfield set toapproved.
From GitLab 15.0, status checks are only set to a passing state if the status field is both present
and set to passed. Requests that:
- Do not contain the
statusfield will be rejected with a400error. For more information, see the relevant issue. - Contain any value other than
passed, such asapproved, cause the status check to fail. For more information, see the relevant issue.
To align with this change, API calls to list external status checks also return the value of passed rather than
approved for status checks that have passed.
OAuth implicit grant
Announced in 14.0
The OAuth implicit grant authorization flow is no longer supported. Any applications that use OAuth implicit grant must switch to alternative supported OAuth flows.
OAuth tokens without an expiration
Announced in 14.3
GitLab no longer supports OAuth tokens without an expiration.
Any existing token without an expiration has one automatically generated and applied.
Optional enforcement of SSH expiration
Announced in 14.8
Disabling SSH expiration enforcement is unusual from a security perspective and could create unusual situations where an expired key is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so now we enforce expiration on all SSH keys.
Optional enforcement of personal access token expiration
Announced in 14.8
Allowing expired personal access tokens to be used is unusual from a security perspective and could create unusual situations where an expired key is unintentionally able to be used. Unexpected behavior in a security feature is inherently dangerous and so we now do not let expired personal access tokens be used.
Required pipeline configurations in Premium tier
Announced in 14.8
Required pipeline configuration helps to define and mandate organization-wide pipeline configurations and is a requirement at an executive and organizational level. To align better with our pricing philosophy, this feature is removed from the Premium tier in GitLab 15.0. This feature continues to be available in the GitLab Ultimate tier.
We recommend customers use Compliance Pipelines, also in GitLab Ultimate, as an alternative as it provides greater flexibility, allowing required pipelines to be assigned to specific compliance framework labels.
This change also helps GitLab remain consistent in our tiering strategy with the other related Ultimate-tier features:
omniauth-kerberos gem
Announced in 14.3
The omniauth-kerberos gem is no longer supported. This gem has not been maintained and has very little usage. Therefore, we
removed support for this authentication method and recommend using SPNEGO instead. You can
follow the upgrade instructions
to upgrade from the removed integration to the new supported one.
We are not removing Kerberos SPNEGO integration. We are removing the old password-based Kerberos.
Create
Feature flag PUSH_RULES_SUPERSEDE_CODE_OWNERS
Announced in 14.8
The feature flag PUSH_RULES_SUPERSEDE_CODE_OWNERS has been removed in GitLab 15.0. From now on, push rules will supersede CODEOWNERS. The CODEOWNERS feature is no longer available for access control.
defaultMergeCommitMessageWithDescription GraphQL API field
Announced in 14.5
The GraphQL API field defaultMergeCommitMessageWithDescription has been removed in GitLab 15.0. For projects with a commit message template set, it will ignore the template.
Verify
API: stale status returned instead of offline or not_connected
Announced in 14.6
A breaking change was made to the Runner API endpoints in 15.0.
Instead of the GitLab Runner API endpoints returning offline and not_connected for runners that have not
contacted the GitLab instance in the past three months, the API endpoints now return the stale value,
which was introduced in 14.6.
artifacts:report:cobertura keyword
Announced in 14.8
As of GitLab 15.0, the artifacts:report:cobertura keyword has been replaced by
artifacts:reports:coverage_report. Cobertura is the only
supported report file, but this is the first step towards GitLab supporting other report types.
Known host required for GitLab Runner SSH executor
Announced in 14.5
In GitLab 14.3, we added a configuration setting in the GitLab Runner config.toml. This setting, [runners.ssh.disable_strict_host_key_checking], controls whether or not to use strict host key checking with the SSH executor.
In GitLab 15.0, the default value for this configuration option has changed from true to false. This means that strict host key checking will be enforced when using the GitLab Runner SSH executor.
Runner status not_connected API value
Announced in 14.6
The GitLab Runner REST and GraphQL API endpoints
deprecated the not_connected status value in GitLab 14.6 and will start returning never_contacted in its place
starting in GitLab 15.0.
Runners that have never contacted the GitLab instance will also return stale if created more than 3 months ago.
type and types keyword from CI/CD configuration
Announced in 14.6
The type and types CI/CD keywords is removed in GitLab 15.0, so pipelines that use these keywords fail with a syntax error. Switch to stage and stages, which have the same behavior.
Test coverage project CI/CD setting
Announced in 14.8
To specify a test coverage pattern, in GitLab 15.0 the project setting for test coverage parsing has been removed.
To set test coverage parsing, use the project’s .gitlab-ci.yml file by providing a regular expression with the
coverage keyword.
Package
Container registry authentication with htpasswd
Announced in 14.9
The Container Registry supports authentication with htpasswd. It relies on an Apache htpasswd file, with passwords hashed using bcrypt.
Since it isn't used in the context of GitLab (the product), htpasswd authentication will be deprecated in GitLab 14.9 and removed in GitLab 15.0.
GraphQL permissions change for Package settings
Announced in 14.9
The GitLab Package stage offers a Package Registry, Container Registry, and Dependency Proxy to help you manage all of your dependencies using GitLab. Each of these product categories has a variety of settings that can be adjusted using the API.
The permissions model for GraphQL is being updated. After 15.0, users with the Guest, Reporter, and Developer role can no longer update these settings:
- Package Registry settings
- Container Registry cleanup policy
- Dependency Proxy time-to-live policy
- Enabling the Dependency Proxy for your group
The issue for this removal is GitLab-#350682
Versions from PackageType
Announced in 14.5
As part of the work to create a Package Registry GraphQL API, the Package group deprecated the Version type for the basic PackageType type and moved it to PackageDetailsType.
In GitLab 15.0, we will completely remove Version from PackageType.
dependency_proxy_for_private_groups feature flag
Announced in 14.5
A feature flag was introduced in GitLab 13.7 as part of the change to require authentication to use the Dependency Proxy. Before GitLab 13.7, you could use the Dependency Proxy without authentication.
In GitLab 15.0, we will remove the feature flag, and you must always authenticate when you use the Dependency Proxy.
Pipelines field from the version field
Announced in 14.5
In GraphQL, there are two pipelines fields that you can use in a PackageDetailsType to get the pipelines for package versions:
- The
versionsfield'spipelinesfield. This returns all the pipelines associated with all the package's versions, which can pull an unbounded number of objects in memory and create performance concerns. - The
pipelinesfield of a specificversion. This returns only the pipelines associated with that single package version.
To mitigate possible performance problems, we will remove the versions field's pipelines field in GitLab 15.0. Although you will no longer be able to get all pipelines for all versions of a package, you can still get the pipelines of a single version through the remaining pipelines field for that version.
Update to the Container Registry group-level API
Announced in 14.5
In GitLab 15.0, support for the tags and tags_count parameters will be removed from the Container Registry API that gets registry repositories from a group.
The GET /groups/:id/registry/repositories endpoint will remain, but won't return any info about tags. To get the info about tags, you can use the existing GET /registry/repositories/:id endpoint, which will continue to support the tags and tag_count options as it does today. The latter must be called once per image repository.
Secure
DS_DEFAULT_ANALYZERS environment variable
Announced in 14.0
We are removing the DS_DEFAULT_ANALYZERS environment variable from Dependency Scanning on May 22, 2022 in 15.0. After this removal, this variable's value will be ignored. To configure which analyzers to run with the default configuration, you should use the DS_EXCLUDED_ANALYZERS variable instead.
Dependency Scanning default Java version changed to 17
Announced in 14.10
For Dependency Scanning, the default version of Java that the scanner expects will be updated from 11 to 17. Java 17 is the most up-to-date Long Term Support (LTS) version. Dependency Scanning continues to support the same range of versions (8, 11, 13, 14, 15, 16, 17), only the default version is changing. If your project uses the previous default of Java 11, be sure to set the DS_JAVA_VERSION variable to match. Please note that consequently the default version of Gradle is now 7.3.3.
End of support for Python 3.6 in Dependency Scanning
Announced in 14.8
For those using Dependency Scanning for Python projects, we are removing support for the default gemnasium-python:2 image which uses Python 3.6, as well as the custom gemnasium-python:2-python-3.9 image which uses Python 3.9. The new default image as of GitLab 15.0 will be for Python 3.9 as it is a supported version and 3.6 is no longer supported.
Retire-JS Dependency Scanning tool
Announced in 14.8
We have removed support for retire.js from Dependency Scanning as of May 22, 2022 in GitLab 15.0. JavaScript scanning functionality will not be affected as it is still being covered by Gemnasium.
If you have explicitly excluded retire.js using the DS_EXCLUDED_ANALYZERS variable, then you will be able to remove the reference to retire.js. If you have customized your pipeline’s Dependency Scanning configuration related to the retire-js-dependency_scanning job, then you will want to switch to gemnasium-dependency_scanning. If you have not used the DS_EXCLUDED_ANALYZERS to reference retire.js, or customized your template specifically for retire.js, you will not need to take any action.
bundler-audit Dependency Scanning tool
Announced in 14.8
We are removing bundler-audit from Dependency Scanning on May 22, 2022 in 15.0. After this removal, Ruby scanning functionality will not be affected as it is still being covered by Gemnasium.
If you have explicitly excluded bundler-audit using the DS_EXCLUDED_ANALYZERS variable, then you will be able to remove the reference to bundler-audit. If you have customized your pipeline’s Dependency Scanning configuration related to the bundler-audit-dependency_scanning job, then you will want to switch to gemnasium-dependency_scanning. If you have not used the DS_EXCLUDED_ANALYZERS to reference bundler-audit or customized your template specifically for bundler-audit, you will not need to take any action.
Configure
GitLab Serverless
Announced in 14.3
All functionality related to GitLab Serverless was deprecated in GitLab 14.3 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to explore using the following technologies with GitLab CI/CD:
For additional context, or to provide feedback regarding this change, please reference our deprecation issue.
Managed-Cluster-Applications.gitlab-ci.yml
Announced in 14.0
The Managed-Cluster-Applications.gitlab-ci.yml CI/CD template is being removed. If you need an alternative, try the Cluster Management project template instead. If your are not ready to move, you can copy the last released version of the template into your project.
Self-managed certificate-based integration with Kubernetes feature flagged
Announced in 14.5
In 15.0 the certificate-based integration with Kubernetes will be disabled by default.
After 15.0, you should use the agent for Kubernetes to connect Kubernetes clusters with GitLab. The agent for Kubernetes is a more robust, secure, and reliable integration with Kubernetes. How do I migrate to the agent?
If you need more time to migrate, you can enable the certificate_based_clusters feature flag, which re-enables the certificate-based integration.
In GitLab 16.0, we will remove the feature, its related code, and the feature flag. GitLab will continue to fix any security or critical issues until 16.0.
Monitor
ELK stack logging
Announced in 14.7
The logging features in GitLab allow users to install the ELK stack (Elasticsearch, Logstash, and Kibana) to aggregate and manage application logs. Users could search for relevant logs in GitLab directly. However, since deprecating certificate-based integration with Kubernetes clusters and GitLab Managed Apps, this feature is no longer available. For more information on the future of logging and observability, you can follow the issue for integrating Opstrace with GitLab.
Jaeger integration
Announced in 14.7
Tracing in GitLab is an integration with Jaeger, an open-source end-to-end distributed tracing system. GitLab users could previously navigate to their Jaeger instance to gain insight into the performance of a deployed application, tracking each function or microservice that handles a given request. Tracing in GitLab was deprecated in GitLab 14.7, and removed in 15.0. To track work on a possible replacement, see the issue for Opstrace integration with GitLab.
Request profiling
Announced in 14.8
Request profiling has been removed in GitLab 15.0.
We're working on consolidating our profiling tools and making them more easily accessible. We evaluated the use of this feature and we found that it is not widely used. It also depends on a few third-party gems that are not actively maintained anymore, have not been updated for the latest version of Ruby, or crash frequently when profiling heavy page loads.
For more information, check the summary section of the deprecation issue.
Protect
Container Network and Host Security
Announced in 14.8
All functionality related to the Container Network Security and Container Host Security categories was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. Users who need a replacement for this functionality are encouraged to evaluate the following open source projects as potential solutions that can be installed and managed outside of GitLab: AppArmor, Cilium, Falco, FluentD, Pod Security Admission. To integrate these technologies with GitLab, add the desired Helm charts in your copy of the Cluster Management Project Template. Deploy these Helm charts in production by calling commands through GitLab CI/CD.
As part of this change, the following capabilities within GitLab are scheduled for removal in GitLab 15.0:
- The Security & Compliance > Threat Monitoring page.
- The Network Policy security policy type, as found on the Security & Compliance > Policies page.
- The ability to manage integrations with the following technologies through GitLab: AppArmor, Cilium, Falco, FluentD, and Pod Security Policies.
- All APIs related to the above functionality.
For additional context, or to provide feedback regarding this change, please reference our deprecation issue.
Vulnerability Check
Announced in 14.8
The vulnerability check feature was deprecated in GitLab 14.8 and is scheduled for removal in GitLab 15.0. We encourage you to migrate to the new security approvals feature instead. You can do so by navigating to Security & Compliance > Policies and creating a new Scan Result Policy.
The new security approvals feature is similar to vulnerability check. For example, both can require approvals for MRs that contain security vulnerabilities. However, security approvals improve the previous experience in several ways:
-
Users can choose who is allowed to edit security approval rules. An independent security or compliance team can therefore manage rules in a way that prevents development project maintainers from modifying the rules.
-
Multiple rules can be created and chained together to allow for filtering on different severity thresholds for each scanner type.
-
A two-step approval process can be enforced for any desired changes to security approval rules.
-
A single set of security policies can be applied to multiple development projects to allow for ease in maintaining a single, centralized ruleset.
Enablement
Background upload for object storage
Announced in 14.9
To reduce the overall complexity and maintenance burden of GitLab's object storage feature, support for using background_upload has been removed in GitLab 15.0.
This impacts a small subset of object storage providers, including but not limited to:
- OpenStack Customers using OpenStack need to change their configuration to use the S3 API instead of Swift.
- RackSpace Customers using RackSpace-based object storage need to migrate data to a different provider.
If your object storage provider does not support background_upload, please migrate objects to a supported object storage provider.
Elasticsearch 6.8.x in GitLab 15.0
Announced in 14.8
Elasticsearch 6.8 support has been removed in GitLab 15.0. Elasticsearch 6.8 has reached end of life. If you use Elasticsearch 6.8, you must upgrade your Elasticsearch version to 7.x prior to upgrading to GitLab 15.0. You should not upgrade to Elasticsearch 8 until you have completed the GitLab 15.0 upgrade.
View the version requirements for details.
Gitaly nodes in virtual storage
Announced in 13.12
Configuring the Gitaly nodes directly in the virtual storage's root configuration object has been deprecated in GitLab 13.12 and is no longer supported in GitLab 15.0. You must move the Gitaly nodes under the 'nodes' key as described in the Praefect configuration.
Move Gitaly Cluster Praefect database_host_no_proxy and database_port_no_proxy configs
Announced in 14.0
The Gitaly Cluster configuration keys for praefect['database_host_no_proxy'] and praefect['database_port_no_proxy'] are replaced with praefect['database_direct_host'] and praefect['database_direct_port'].
Move custom_hooks_dir setting from GitLab Shell to Gitaly
Announced in 14.9
The custom_hooks_dir setting is now configured in Gitaly, and is removed from GitLab Shell in GitLab 15.0.
Pseudonymizer
Announced in 14.7
The Pseudonymizer feature is generally unused, can cause production issues with large databases, and can interfere with object storage development. It was removed in GitLab 15.0.
promote-to-primary-node command from gitlab-ctl
Announced in 14.5
In GitLab 14.5, we introduced the command gitlab-ctl promote to promote any Geo secondary node to a primary during a failover. This command replaces gitlab-ctl promote-to-primary-node which was only usable for single-node Geo sites. gitlab-ctl promote-to-primary-node has been removed in GitLab 15.0.
SUSE Linux Enterprise Server 12 SP2
Announced in 14.5
Long term service and support (LTSS) for SUSE Linux Enterprise Server (SLES) 12 SP2 ended on March 31, 2021. The CA certificates on SP2 include the expired DST root certificate, and it's not getting new CA certificate package updates. We have implemented some workarounds, but we will not be able to continue to keep the build running properly.
Sidekiq configuration for metrics and health checks
Announced in 14.7
In GitLab 15.0, you can no longer serve Sidekiq metrics and health checks over a single address and port.
To improve stability, availability, and prevent data loss in edge cases, GitLab now serves Sidekiq metrics and health checks from two separate servers.
When you use Omnibus or Helm charts, if GitLab is configured for both servers to bind to the same address, a configuration error occurs. To prevent this error, choose different ports for the metrics and health check servers:
If you installed GitLab from source, verify manually that both servers are configured to bind to separate addresses and ports.
Support for gitaly['internal_socket_dir']
Announced in 14.10
Gitaly introduced a new directory that holds all runtime data Gitaly requires to operate correctly. This new directory replaces the old internal socket directory, and consequentially the usage of gitaly['internal_socket_dir'] was deprecated in favor of gitaly['runtime_dir'].
Support for legacy format of config/database.yml
Announced in 14.3
The syntax of GitLab's database
configuration located in database.yml has changed and the legacy format has been removed.
The legacy format supported a single PostgreSQL adapter, whereas the new format supports multiple databases.
The main: database needs to be defined as a first configuration item.
This change only impacts users compiling GitLab from source, all the other installation methods handle this configuration automatically. Instructions are available in the source update documentation.
The promote-db command is no longer available from gitlab-ctl
Announced in 14.5
In GitLab 14.5, we introduced the command gitlab-ctl promote to promote any Geo secondary node to a primary during a failover. This command replaces gitlab-ctl promote-db which is used to promote database nodes in multi-node Geo secondary sites. The gitlab-ctl promote-db command has been removed in GitLab 15.0.
