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.
