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.
Deprecation date:
May 22, 2021
Auto DevOps: Stable Auto Deploy template renewal
In GitLab 14.0, we will renew the Auto Deploy CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 auto-deploy-image. This latest template is opt-in. Unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the v1 auto-deploy-image.
Since the v1 and v2 versions are not backwards compatible, your project might encounter an unexpected failure if you already have a deployed application. Please follow the upgrade guide to upgrade your environments. You can also start using the latest template today by following the early adoption guide.
Deprecation date:
May 22, 2021
CI/CD pipeline behavior changes in GitLab 14.0
In GitLab 14.0, we intend to make some changes to the behavior of CI/CD pipelines to improve performance and resource usage:
- Scheduled pipeline that run very frequently can impact an instance’s performance. In GitLab 14.0, the frequency of scheduled pipelines will be subject to GitLab application limits. For self-managed instances, admins will have the option to change or disable these limits, which can reduce the problems caused by performance-impacting cron patterns in pipeline schedules.
- In some edge cases, users were accidentally triggering both branch pipelines and merge request pipelines at the same time, wasting resources. We are working to add a default
workflow: rule
in GitLab 14.0 to reduce the risk of this happening. Users with pipelines configured to rely on this behavior can easily override the new default with their own workflow: rule
to re-enable the previous behavior.
Deprecation date:
May 22, 2021
Code Quality Rubocop support changing
Currently, by default, the Code Quality feature does not provide support for Ruby 2.6+ if you’re using the Code Quality template.
To better support the latest versions of Ruby, the default Rubocop version is being changed to add support for Ruby 2.4 through 3.0. As a result, support for Ruby 2.1, 2.2, and 2.3 will be dropped. You can reenable support for older versions by customizing your configuration.
Relevant Issue: Default codeclimate-rubocop engine does not support Ruby 2.6+
Deprecation date:
May 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. GitLab 13.9 deprecates Clair. This is not a hard breaking change, as customers who wish to continue to use Clair can do so by setting the CS_MAJOR_VERSION
variable to version 3 (or earlier) in their gitlab-ci.yaml
file. Since Clair is deprecated, however, note that GitLab will no longer update or maintain that scanning engine beginning in the 14.0 release. We advise customers to use the new default of Trivy beginning in GitLab 14.0 for regular updates and the latest features. Customers can provide feedback and get additional details on our open deprecation issue.
Deprecation date:
May 22, 2021
DAST environment variable renaming and removal
GitLab 13.8 renames multiple environment variables to support their broader usage in different workflows. In GitLab 14.0, the old variables will be permanently removed and will no longer work. Any configurations using these variables must be updated to the new variable names. Any scans using these variables in GitLab 14.0 and later will fail to be configured correctly. These variables are:
DAST_AUTH_EXCLUDE_URLS
becomes DAST_EXCLUDE_URLS
.
AUTH_EXCLUDE_URLS
becomes DAST_EXCLUDE_URLS
.
AUTH_USERNAME
becomes DAST_USERNAME
.
AUTH_PASSWORD
becomes DAST_PASSWORD
.
AUTH_USERNAME_FIELD
becomes DAST_USERNAME_FIELD
.
AUTH_PASSWORD_FIELD
becomes DAST_PASSWORD_FIELD
.
DAST_ZAP_USE_AJAX_SPIDER
will now be DAST_USE_AJAX_SPIDER
.
DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED
will be removed, since the feature is being removed.
Deprecation date:
Jun 22, 2021
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
Deprecation date:
May 22, 2021
Currently, GitLab supports:
- Text, JSON, and logstash log formatting for app logs.
- Text, JSON, and combined log formatting for access logs.
We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.
Deprecation date:
February 22, 2021
Deprecate Container Registry logging hooks
The Container Registry currently supports logging hooks that can only be used for email notifications.
These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.
In an effort to simplify the registry features and configurations, we will drop support for logging hooks.
Deprecation date:
February 22, 2021
Deprecate Container Registry maxidle and maxactive Redis pool settings
Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.
We intend to:
- Remove the
redis.pool.maxidle
and redis.pool.maxactive
settings.
- Add
redis.pool.size
(maximum number of connections), redis.pool.minidle
(minimum number of idle connections), and redis.pool.maxlifetime
(maximum amount of time a connection may be reused) settings.
Deprecation date:
February 22, 2021
Deprecate Container Registry support for Bugsnag
Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.
Deprecation date:
February 22, 2021
Deprecate Container Registry support for NewRelic
NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.
Deprecation date:
February 22, 2021
Deprecate Container Registry support for TLS 1.0 and 1.1
Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.
We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.
Deprecation date:
February 22, 2021
Deprecate disk source configuration for GitLab Pages
GitLab Pages API-based configuration has been available since GitLab 13.0 and will replace the disk
source configuration, which will be removed in GitLab 14.0. We recommend that you move away from using disk
source configuration and move to gitlab
for an API-based configuration, since disk
will no longer be supported and cannot be chosen. You can migrate away from the ‘disk’ source configuration by setting gitlab_pages['domain_config_source'] = "gitlab"
in your gitlab.rb/etc/gitlab/gitlab.rb
file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.
Deprecation date:
May 22, 2021
Deprecate pulls that use v1 of the Docker registry API
GitLab disabled pulls via the Docker registry v1 APIs on January 22, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.
Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:
- Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
- If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.
Deprecation date:
February 22, 2021
Deprecating Service Templates
Service Templates are now deprecated and scheduled to be removed in GitLab 14.0. They were used to apply identical settings to a large number of projects, but they only did so at the time of project creation.
While they solved part of the problem, updating those values later proved to be a major pain point. Project Integration Management solves this problem by enabling you to create settings at the Group or Instance level, and projects within that namespace inheriting those settings.
Deprecation date:
May 22, 2021
Deprecating global `SAST_ANALYZER_IMAGE_TAG` in SAST CI template
With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity into our release process. Currently GitLab shares a major version number for all our analyzers and tools. This requires all tools to share a major version and prevent the use of semantic version numbering. Beginning in 14.0 GitLab SAST will deprecate the SAST_ANALYZER_IMAGE_TAG
global variable in our managed SAST.gitlab-ci.yml CI template in favor of analyzer job variable setting the ‘major.minor’ tag in the SAST vendored template. Each analyzer job will have a scoped SAST_ANALYZER_IMAGE_TAG
variable which will be actively managed by GitLab and set to the ‘major.minor’ tag for the respective analyzer. To pin to a specific version you simply change the variable value to the specific version tag.
If you override or maintain custom versions of SAST.gitlab-ci.yml
you will want to update your CI templates to stop referencing the global SAST_ANALYZER_IMAGE_TAG
and move it to a scoped analyzer job tag. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. This change will allow you to instead override with a pinned major.minor
version to more granular control future analyzer updates. This change will happen with GitLab 14.0 releasing May 22, 2021.
This deprecation and planned removal changes our previously annouced plan to Pin the Static Analysis tools.
Deprecation date:
May 22, 2021
Deprecation of disk/NFS storage for GitLab Pages
To make GitLab Pages cloud-native compatible, starting in GitLab 14.0, we’re changing the underlying storage format used by GitLab Pages to object storage in GitLab 14.0.
Your migration to the new storage format is designed to be automatic, however, it may require some human intervention. To ease this transition into object storage, a temporary flag gitlab_pages['use_legacy_storage'] = true
will be available from GitLab 14.0 to 14.3, but it will be removed in GitLab 14.4.
In 13.11 you will be able to migrate to the new architecture earlier and test it in your environment prior 14.0.
Deprecation date:
May 22, 2021
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.
Deprecation date:
May 22, 2021
Deprecations for Dependency Scanning
We are reiterating the upcoming deprecations for Dependency Scanning in 14.0, as mentioned in 13.9 and this blog post.
Previously to exclude a DS analyzer, you needed to remove it from the default list of analyzers and use that to set the DS_DEFAULT_ANALYZERS
variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. As a result we ask you to migrate from DS_DEFAULT_ANALYZERS
to DS_EXCLUDED_ANALYZERS
when it is available. Read about it in issue #287691.
Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE
env variable. This is not documented properly and its naming is inconsistent with the equivalent BUNDLER_AUDIT_UPDATE_DISABLED
variable. As a result we ask you to migrate from GEMNASIUM_DB_UPDATE
to GEMNASIUM_UPDATE_DISABLED
when it is available. Read about it in issue #215483.
Deprecation date:
May 22, 2021
Expired SSH keys disabled by default
Starting in GitLab 14.0, SSH keys added to GitLab that have expired
will be disabled by default. This is
a change from the current behavior where expired SSH keys can still be used unless explicitly
disabled by an administrator.
Administrators can still allow the use of expired keys in the same way as they
can override expiration settings for Personal Access Tokens.
Deprecation date:
May 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.
Deprecation date:
May 22, 2021
Git default branch name change
Every Git repository has an initial branch. It’s the first branch to be created automatically when you create a new repository. By default, this initial branch is named master
. Future Git versions will change the default branch name in Git from master
to main
. In coordination with the Git project and the broader community, GitLab will be changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.
GitLab has already introduced changes that allow users to change the default branch name both at the instance-level (for self-managed users) and at the group-level (for both SaaS and self-managed users). We encourage users to make use of these features to set default branch names on new projects.
For more information, see the related epic and related blog post.
Deprecation date:
May 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.
Deprecation date:
May 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.
Deprecation date:
Jun 22, 2021
Helm v2 support
Helm v2 was officially deprecated in November of 2020, with the stable
repository being de-listed from the Helm Hub shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the GitLab Helm chart, Helm v2 will no longer be supported.
Users of the chart should upgrade to Helm v3 to deploy GitLab 14.0 and above.
Deprecation date:
May 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.
Deprecation date:
May 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.
Deprecation date:
May 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.
Deprecation date:
Jun 22, 2021
NFS for Git repository storage deprecated
With the general availability of Gitaly Cluster
(introduced in GitaLab 13.0), we are deprecating
support for NFS for Git repositories in GitLab 14.0.
We want to help you avoid purchasing expensive NFS appliances
they won’t need, so invite customers currently using NFS for Git repositories to
begin planning their migration.
To see our overall status, please review our Gitaly Cluster roadmap.
Deprecation date:
May 22, 2021
One-click GitLab Managed Apps will be removed in GitLab 14.0
We are deprecating one-click install of GitLab Managed Apps. Although they made it very easy to get started with deploying to Kubernetes from GitLab, the overarching community feedback was that they were not flexible or customizable enough for real-world Kubernetes applications. Instead, our future direction will focus on installing apps on Kubernetes via GitLab CI/CD in order to provide a better balance between ease-of-use and expansive customization.
We plan to remove one-click Managed Apps completely in GitLab version 14.0. This will not affect how existing managed applications run inside your cluster, however, you’ll no longer have the ability to update modify those applications via the GitLab UI. We recommend cluster administrators plan to migrate any existing managed applications by reinstalling them either manually or via CI/CD. Migration instructions will be available in our documentation later.
Deprecation date:
May 22, 2021
PostgreSQL 11 support
PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.
Starting in GitLab 13.7, all new installations default to version 12. From GitLab 13.8, single-node instances are automatically upgraded as well. If you aren’t ready to upgrade, you can opt-out of automatic upgrades.
Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.
Deprecation date:
May 22, 2021
Removal of legacy fields from DAST report
As a part of the migration to a common report format for all of the Secure scanners in GitLab, DAST is making changes to the DAST JSON report. Certain legacy fields are being deprecated in 13.8 and will be completely removed in 14.0. These fields are @generated
, @version
, site
, and spider
. This should not affect any normal DAST operation, but does affect users who consume the JSON report in an automated way and use these fields. Anyone impacted by these changes who needs these fields for business reasons is encouraged to open a new GitLab issue and explain the need.
For more information, see the removal issue.
Deprecation date:
Jun 22, 2021
Remove /usr/lib/gitlab-runner symlink from package
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.
Deprecation date:
Jun 22, 2021
Remove AUTHORIZED_KEYS integration for SSH key lookup
Currently, GitLab has three different mechanisms by which it can
look up the user attached to an SSH key when signing in. Those are:
- Integration via
authorized_keys
- Fast lookup of SSH keys
- Lookup via SSH certificate
The first mechanism (integration via authorized keys
) is vulnerable to both race conditions and
out-of-order execution issues, making it hard to scale. Because of this it will be removed in
GitLab 14.0. Refer to issue #212227 for details.
Deprecation date:
May 22, 2021
Remove DAST default template stages
In GitLab 14.0, the stages defined in the current DAST.gitlab-ci.yml
template will be removed to avoid the situation where the template overrides manual changes made by DAST users. This change is being made in response to customer issues where the stages in the template cause problems when used with customized DAST configurations. Because of this removal, gitlab-ci.yml
configurations that do not specify a dast
stage must be updated to include this stage.
In GitLab 13.8, the stages are deprecated and the changes to remove them from the template are included in the DAST.latest.gitlab-ci.yml
template. Anyone can test and see if any changes are needed in their configuration files.
Deprecation date:
Jun 22, 2021
Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag
In GitLab Runner 13.1, issue #3376, we introduced sigterm
and then sigkill
to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL
, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.
Deprecation date:
Jun 22, 2021
Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag
In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER
feature flag. Refer to issue #27175 for details.
Deprecation date:
Jun 22, 2021
Remove GLOBAL_DEFAULT_BRANCH_NAME feature flag
In GitLab release 14.0 we will remove the GLOBAL_DEFAULT_BRANCH_NAME
feature flag. Refer to issue #325163
for details.
Deprecation date:
May 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.
Deprecation date:
May 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.
Deprecation date:
Jun 22, 2021
Remove legacy DAST domain validation
Starting with GitLab 13.8, the current method of DAST Domain Validation for CI/CD scans is deprecated. In GitLab 14.0, the legacy DAST validation method will be removed. This method of domain validation only disallows scans if the DAST_FULL_SCAN_DOMAIN_VALIDATION_REQUIRED
environment variable is set to true
in the gitlab-ci.yml
file, and a Gitlab-DAST-Permission
header on the site is not set to allow
. This two-step method created a situation in which users had to opt-in to using the variable before they could opt-out from using the header. For users concerned about protecting a site against a full, active scan, permission for a GitLab DAST scan can still be revoked by adding to any website a Gitlab-DAST-Permission
header with a value of deny
. This continues to block GitLab DAST scans attempted against any website that includes this HTTP header.
For more information, see the removal issue.
Deprecation date:
Jun 22, 2021
Remove off peak time mode configuration for Docker Machine autoscaling
In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.
Deprecation date:
Jun 22, 2021
Remove success and failure for finished build metric conversion
In GitLab Runner 13.5, we introduced failed
and success
states for a job. To support Prometheus rules, we chose to convert success/failure
to finished
for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.
Deprecation date:
Jun 22, 2021
Remove translation from step_script to build_script in custom executor
In GitLab Runner 13.2 a translation for step_script
to build_script
was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.
Deprecation date:
Jun 22, 2021
The default method of invoking Sidekiq will be `sidekiq-cluster`
In GitLab 13.0 we deprecated alternative ways of starting Sidekiq
in favor of Sidekiq Cluster. Sidekiq Cluster provides additional
options for managing Sidekiq queues and scaling.
This enables running multiple Sidekiq
processes.
Multiple Sidekiq processes allow a GitLab instance to continue to
scale vertically, and are often a good first step prior to adding
additional nodes. In addition, this will allow us to simplify
support and improve maintainability for GitLab.com.
Directly invoking Sidekiq will no longer be supported as of GitLab 14.0.
For Omnibus installations, this should be entirely automatic. For Helm
installations that set the queues
option, see the documentation on
upgrading.
Deprecation date:
May 22, 2021
Ubuntu 16.04 support
Ubuntu 16.04 will reach end-of-life in April 2021, and no longer receive maintenance updates. We strongly recommend users to upgrade to a newer release, such as 20.04.
GitLab 13.11 will be the last release with Ubuntu 16.04 support.
Deprecation date:
May 22, 2021
Unicorn will be removed in favor of Puma for GitLab self-managed
Unicorn support is deprecated and will be removed in GitLab 14.0. You must migrate to Puma before upgrading to GitLab 14.0.
Deprecation date:
May 22, 2021
Update CI/CD templates to stop using hardcoded 'master'
Our CI/CD templates will be updated so that they no longer use hard-coded references to a master
branch. In 14.0, they will all be changed to use a CI/CD variable that points to your project’s configured default branch instead. If your CI/CD pipeline relies on our built-in templates, you may want to verify that this change will work with your current configuration. For example, if you have a master branch and a different default branch, the updates to the templates may cause changes to your pipeline behavior.
Deprecation date:
May 17, 2021
Web Application Firewall (WAF)
GitLab’s Web Application Firewall (WAF) is deprecated in GitLab 13.6. As this is a breaking change, the WAF will be removed from the product on May 22, 2021 in GitLab 14.0. GitLab’s WAF had limitations inherent in the architectural design that made it difficult to meet the requirements traditionally expected of a WAF. By deprecating and removing the WAF, GitLab will be able to focus its efforts on furthering other areas in the product where more value can be provided to users. Users who currently rely on GitLab’s WAF can continue to use the free and open source modsecurity project which is independent from GitLab. Additional details are available in the deprecation issue.
Deprecation date:
November 22nd, 2020
project-ref-sha repo archival route removal
Prior to GitLab 10.7 the method used to archive repositories returned
an archive named project-ref-sha
and a parent directory of the same name.
This made the process of packaging releases more difficult as you had to
know both the tag and the SHA.
GitLab 10.7 added the project-ref
route which simplifies packaging by
adding a route that returns an archive project-ref
.
The old project-ref-sha
will be removed in GitLab 14.0.
Deprecation date:
May 22, 2021