Deprecations
GitLab Geo will enforce Hashed Storage in GitLab 12.0
GitLab Geo requires Hashed
Storage
to mitigate race conditions on secondary nodes. This was noted in
gitlab-ce#40970.
In GitLab 11.5, we added this
requirement to the Geo documentation in gitlab-ee#8053.
With GitLab 11.6,
sudo gitlab-rake gitlab:geo:check checks that Hashed
Storage is enabled and all projects are migrated. See
gitlab-ee#8289. 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:
gitlab-ee!8433.
In GitLab 12.0, Geo will
enforce the Hashed Storage requirement. See
gitlab-ee#8690.
Planned removal date:
Jun. 22, 2019
GitLab Geo will enforce using PG FDW in GitLab 12.0
This is needed for Geo Log Cursor as this significantly improves the performance of some synchronization operations.
It also improves the performance of the Geo node status queries.
For large projects, the legacy queries had unacceptable performance.
See how to set it up in Geo database replication
In GitLab 12.0, Geo will
enforce the PG FDW. See
gitlab-ee#11006.
Planned removal date:
Jun. 22, 2019
Sentry settings for error reporting and logging will be removed from the UI in GitLab 12.0
These settings will be removed from the UI in GitLab 12.0 and made available within gitlab.yml.
In addition, you will be able to define a Sentry Environment to differentiate between multiple deployments. For example, development, staging, and production. See gitlab-ce#49771.
Planned removal date:
Jun. 22, 2019
Limit maximum number of pipelines created by a single push
Previously, GitLab would create pipelines for the HEAD of every branch included in a push.
That makes sense for developers that may be pushing more than one change at a time (say to a feature branch, and the develop branch).
However, when pushing a large repository with many active branches – perhaps to move, mirror, or fork it from another location –
it does not make sense to create a pipeline for every branch. Starting in GitLab 11.10, we will create a
maximum of 4 pipelines during a push operation.
Planned removal date:
May 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 will be 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 will no longer be 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 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 will 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 distribution 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 will no longer distribute packages to those Linux distributions. A full list of distributions which 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 will start 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.
Since this is a behavior change that may affect some users, we’ve prepared a FF_USE_LEGACY_GIT_CLEAN_STRATEGY
feature flag. When set to true it will restore the legacy cleanup strategy. More about how to
use feature flags in GitLab Runner can be found in the documentation
In GitLab Runner 12.0, GitLab Runner will drop support for the legacy cleanup strategy and remove the
ability to restore it with a feature flag. Please see this issue
Planned removal date:
Jun. 22, 2019
Group project templates fixed to Silver/Premium
When we introduced group-level project templates
in 11.6, we unintentionally made this Premium/Silver feature available at any tier.
We’re fixing this bug
in 11.11 by giving any existing users/instances lower than Silver/Premium
a grace period of three months.
On Aug. 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
Support for Windows batch is now deprecated
We are deprecating 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. We plan to remove Windows batch in GitLab 13.0 (Jun 22, 2020).
For more information, see this issue.
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 - in July Microsoft will be ending support for
the last version of windows that doesn’t support the latest version of
PowerShell. For users that may still want to run items using cmd.exe,
those commands can be still invoked from PowerShell, but we will not provide
direct support for Windows batch.
Planned removal date:
Jun. 22, 2020
Git 2.21.0 or greater required
Beginning with GitLab 11.11, Git 2.21.0 is required to run GitLab.
Omnibus GitLab already ships with Git 2.21.0,
but users of source installations that run older versions of Git will
have to upgrade.
Planned removal date:
May 22, 2019
Remove Kubernetes service template
In GitLab 12.0, 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 use of ‘app’ as matching mechanism for Kubernetes deploy boards
In GitLab 12.0, we plan to remove app label matching for the Kubernetes deployment
selector. 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
GitLab 12.0 packages will be signed with an extended signature
On May 2, 2019, GitLab extended the expiration date of the package signing keys
for Omnibus GitLab packages from 2019-08-01 to 2020-07-01. For those verifying the package signatures, refreshing the keys is as simple as
following our documentation for Omnibus Package Signatures a second time.
Planned removal date:
Jun. 22, 2019
Support for Prometheus 1.x in Omnibus GitLab
With GitLab 11.4,
the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab.
Prometheus 2.0 is now included.
However, the metrics format is incompatible with 1.0. Existing installations
can upgrade to 2.0 and optionally migrate their data
using an included tool.
With GitLab 12.0, any
installation not yet running Prometheus 2.0 will be automatically upgraded. Metric
data from Prometheus 1.0 will not be migrated and will be lost.
Planned removal date:
Jun. 22, 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