Deprecations
GitLab 9.x now out of support scope
As we introduce a new major version of GitLab, GitLab 9.x now falls outside of our scope of support. We invite customers to upgrade to at least GitLab 10.0 to benefit from our Support team’s assistance.
Planned removal date:
Jun. 22, 2019
GitLab Geo requires Hashed Storage in GitLab 12.0
With GitLab 12.0, GitLab Geo requires Hashed Storage
to mitigate race conditions on secondary nodes. Please use sudo gitlab-rake gitlab:geo:check
to see if Hashed Storage is enabled and all projects are migrated. See the
documentation on how to migrate to Hashed Storage.
This was also noted in previously.
In GitLab 11.5, we added this
requirement to the Geo documentation.
With GitLab 11.6,
sudo gitlab-rake gitlab:geo:check checks that Hashed
Storage is enabled and all projects are migrated. If
you are using Geo, please run this check and migrate as soon as possible.
In GitLab 11.8, a
permanently dismissable warning is displayed on the
Admin Area › Geo › Nodes page if the above checks are not resolved.
Planned removal date:
Jun. 22, 2019
GitLab Geo requires PostgreSQL Foreign Data Wrapper in GitLab 12.0
In GitLab 12.0, Geo requires PostgreSQL Foreign Data Wrapper,
raising the minimum PostgreSQL version to 9.6. GitLab Geo uses PostgreSQL Foreign Data Wrapper to query data from different PostgreSQL instances.
This is needed for Geo Log Cursor, as this significantly improves the performance
of some synchronization operations. Foreign Data Wrapper also improves the performance of the Geo node status queries. For large projects, the legacy
queries had unacceptable performance.
See how to set PostgreSQL Foreign Data Wrapper up in the Geo database replication documentation.
Planned removal date:
Jun. 22, 2019
Remove use of app as matching mechanism for Kubernetes deploy boards
In GitLab 12.1, we will remove the app label matching for the Kubernetes deployment
selector (removal was originally scheduled for 12.0). As part of GitLab 11.10, we introduced a new matching mechanism
which uses app.gitlab.com/app and app.gitlab.com/env to show deployments on deploy boards.
In order to see these deployments in your deploy boards, all you need to do is push a new
deployment and GitLab will use the new labels for your deployments.
Planned removal date:
Jun. 22, 2019
Removal of AUTO_DEVOPS_DOMAIN environment variable
The new KUBE_INGRESS_BASE_DOMAIN environment variable was
introduced as part of GitLab 11.8. It is no longer
necessary to use AUTO_DEVOPS_DOMAIN to define multiple domains as these can now be defined individually on the cluster page.
Planned removal date:
Jun. 22, 2019
Remove Kubernetes service template
In GitLab 12.1, we plan to remove the instance-level Kubernetes service
template in favor of the instance-level
cluster functionality introduced in GitLab 11.11.
Any self-managed instance making use of the service template will be migrated to an
instance-level cluster as part of upgrading to GitLab 12.0.
Planned removal date:
Jun. 22, 2019
Remove support for skip_auto_migrations file
In GitLab 12.0, we are completely removing support for skip_auto_migrations file.
This was previously deprecated in GitLab 10.6.
Planned removal date:
Jun. 22, 2019
Remove Prometheus 1.x support
In GitLab 12.0, we are completely removing support for Prometheus 1.x.
Planned removal date:
Jun. 22, 2019
Deprecation of openSUSE 42.3
openSUSE 42.3 reaches end of life on June 30, 2019. We will continue to build packages
for it until GitLab 12.1, with plans to drop support in GitLab 12.2.
Planned removal date:
Jun. 22, 2019
Deprecate legacy code paths in GitLab Runner
Since GitLab 11.9, GitLab Runner has been using a new
method
for cloning/fetching the repository. Currently, GitLab
Runner will use the old method if the new one is not supported. Please see this
issue for
additional details.
In GitLab 11.0, we changed how the metrics server is configured for GitLab
Runner. metrics_server has been removed in favor of listen_address
in GitLab 12.0. Please see this issue for
additional details.
In 11.3, GitLab Runner started supporting multiple cache
providers.
This resulted in new settings for S3-specific
configuration.
In the documentation,
there is a table of what changed, and how to migrate to the new
configuration. Please see this
issue for
additional details.
These paths are no longer available in GitLab 12.0. As a user, you don’t have to change
anything apart from making sure the GitLab instance is running 11.9+
when upgrading to GitLab Runner 12.0.
Planned removal date:
Jun. 22, 2019
Deprecate entrypoint feature flag for GitLab Runner
In GitLab 11.4, GitLab Runner introduced a feature flag
FF_K8S_USE_ENTRYPOINT_OVER_COMMAND
in order to fix issues like
#2338 and
#3536.
In GitLab 12.0, we switch to the correct behavior as if the feature flag was
turned off. Please see this
issue for
additional details.
Planned removal date:
Jun. 22, 2019
Deprecate support of Linux distributions that reached EOL for GitLab Runner
Some Linux distributions in which you could install GitLab Runner have reached
End of Life support.
In GitLab 12.0, GitLab Runner no longer distributes packages to those Linux distributions.
A full list of distributions that are no longer supported can be found in our
documentation.
Thanks Javier Jardón for your
contribution!
Planned removal date:
Jun. 22, 2019
Remove legacy GitLab Runner helper commands
As part of adding support for Windows Docker executor, we had to
deprecate some old commands that are used for the helper
image.
In GitLab 12.0, GitLab Runner starts using the new commands. This only
affects users who are overriding the helper
image.
Please see this
issue for
additional details.
Planned removal date:
Jun. 22, 2019
Remove legacy Git clean mechanism from GitLab Runner
With GitLab Runner 11.10, we introduced a way
to configure how git clean command is being executed by Runner. Additionally, the new cleanup strategy
removes the usage of git reset and moves the git clean command after the checkout step.
In GitLab Runner 12.0, GitLab Runner drops support for the legacy cleanup strategy and removes the
ability to restore it with a feature flag. Please see this issue
Planned removal date:
Jun. 22, 2019
Secure License Management renamed to License Compliance in GitLab 12.0
License Management is being renamed to better align with common industry vernacular starting in GitLab 12.0.
The purpose of License Compliance is to analyze your application to track which licenses are used by third-party components,
like libraries and external dependencies, and check that they are compatible with your project’s licensing model.
License Compliance is part of our Secure Composition Analysis group.
Planned removal date:
Jun. 22, 2019
Deprecated variables and argument for manual configurations of .gitlab-ci.yml when using Secure features
If you have manually configured your .gitlab-ci.yml configuration file to use the:
- Command line argument
--auth-first-page, you need to remove this argument as it is no longer supported.
DEP_SCAN_DISABLE_REMOTE_CHECKS flag variable, you need to remove this as it is no longer supported.sast_container value in GITLAB_FEATURES environment variable, you must change to use container_scanning instead.
If you have manually configured your .gitlab-ci.yml configuration file, verify that you are using the
new report syntax.
All Secure features are dependant on the reports being available in the expected location. If you do not update to the
new report syntax,
all Secure features will stop working.
If you utilize vendored templates
instead of manual configuration, your configuration will be kept up to date with variable and argument changes.
Planned removal date:
Jun. 22, 2019
No maintained manual Secure configuration snippet from GitLab 12.0
We will no longer update the Secure
manual configuration snippet
in the documentation that is utilized when you are configuring Secure features in your project pipeline.
Please use vendored template inclusion for Secure in your .gitlab-ci.yml configuration by using
include: template: Dependency-Scanning.gitlab-ci.yml.
Planned removal date:
Jun. 22, 2019
3DES is now disabled on GitLab.com Pages by default
GitLab.com Pages previously allowed 3DES, which is being deprecated.
To mitigate this, going forward 3DES will be disabled by default. This should not change anything for users of modern browsers,
but some users of Internet Explorer versions 7 and 8 running on the Windows XP operating system may be impacted.
Planned removal date:
Jun. 22, 2019
Remove support for MySQL in GitLab 12.1
GitLab 12.0 is the last version with support for MySQL (and MariaDB).
Users will need to migrate
to PostgreSQL in order to utilize future versions. MySQL has been considered deprecated and
support for it was previously limited to Enterprise Edition Starter and Premium.
If you are a GitLab customer using MySQL, please contact our customer support team
for assistance with the migration.
Planned removal date:
Jul. 22, 2019
Sentry settings for error reporting and logging will be removed from the UI in GitLab 12.1
These settings will be removed from the UI in GitLab 12.1 and have been made available within gitlab.yml in GitLab 11.11. In addition, you will be able to define a Sentry Environment to differentiate between multiple deployments like development, staging, and production. See gitlab-ce#49771 for more details.
Planned removal date:
Jul. 22, 2019
Group project templates fixed to Silver/Premium tier
When we introduced group-level project templates
in GitLab 11.6, we unintentionally made this Premium/Silver feature available at any tier.
We fixed this bug
in GitLab 11.11 by giving any existing users/instances lower than Silver/Premium
a grace period of three months.
On August 22nd, 2019, this grace period will expire and group project
templates will require Silver/Premium or higher as documented.
Planned removal date:
Aug. 22, 2019
License Management will use Python 3 as the default in GitLab 12.2
Python 3 will become the default version used by the Secure stage License Management.
Users with Python 2 will need to set the CI variable LM_PYTHON_VERSION to “2” if they are self-managed when they start using GitLab 12.2.
Users with Python 3 can change the CI variable LM_PYTHON_VERSION to “3” today.
Planned removal date:
Aug. 22nd, 2019
Deprecate support for Windows batch
In GitLab 12.3, we plan to deprecate support for Windows batch command line jobs in the GitLab Runner (e.g. cmd.exe)
in favor of extended and expanding support for Windows PowerShell.
This will align our vision for enterprise DevOps with Microsoft’s position that PowerShell is the right technology
to automate enterprise applications in Windows-based environments.
For users that may still want to run items against cmd.exe, those commands can be invoked from PowerShell,
but we will not provide direct support for Windows batch as there are a number of inconsistencies in batch
which results in a high cost for maintainability and development.
Planned removal date:
Sep. 22, 2019
Deprecation of job directory caching in GitLab Runner with Docker executor
With GitLab Runner 11.10, we’ve changed what part of the job directory is cached in a shared volume
when Docker and Docker Machine executors are used. Instead of caching only the parent directory of the
job working directory, GitLab Runner is now caching the whole base directory configured with
builds_dir. Because it is a behavior change, we’ve added a feature flag that allows to control
whether the new or old behavior should be used.
With GitLab Runner 12.3, we will remove the feature flag and the old behavior. Please see
this issue.
Planned removal date:
Sep. 22, 2019
Python 2 support in Secure License Management will be deprecated by end of the year
Support for Python 2 would be dropped in a future GitLab release due to Python 2.7 reaching the end of its life on January 1st, 2020.
Planned removal date:
Dec. 22nd, 2019
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