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
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.
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
Sidekiq Cluster queue selector configuration option has been renamed
GitLab contains a large number of background job queues. Some administrators may want to have multiple background job processes, each running different workloads.
Previously, we only supported specifying the queues handled for a particular process by name, or using an experimental option to allow selecting queues by attributes.
This option - previously experimental_queue_selector - is no longer experimental and has been renamed to queue_selector. experimental_queue_selector will continue to work until GitLab 14.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
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback