GitLab 14 specific changes
Gitaly runtime directory
In 14.10, Gitaly has introduced a new runtime directory. This directory is intended to hold all files and directories Gitaly needs to create at runtime in order to operate correctly. This includes for example internal sockets, the Git execution environment or the temporary hooks directory.
This new configuration can be set via
gitaly['runtime_dir']. It replaces the
gitaly['internal_socket_dir'] configuration: if the internal socket
directory is not explicitly configured, sockets will be created in the runtime
gitaly['internal_socket_dir'] will be removed in 15.0.
In 14.8, we are upgrading Redis from 6.0.16 to 6.2.6. This upgrade is expected to be fully backwards compatible.
If your instance has Redis HA with Sentinel, follow the upgrade steps documented in Update GitLab installed with the Omnibus GitLab package
Downgrading Grafana from 8.1 to 7.5
In GitLab 14.4 the provided Grafana version is 7.5, this is a downgrade from the Grafana 8.1 version introduced in GitLab 14.3. This was reverted to an Apache-licensed Grafana release to allow time to consider the implications of the newer AGPL-licensed releases.
Users that have customized their Grafana install with plugins or library
panels may experience errors in Grafana after the downgrade. If the errors
persist after a Grafana restart you may need to reset the Grafana db and
re-add the customizations. The Grafana database can be reset with
sudo gitlab-ctl reset-grafana.
Removing support for running Sidekiq directly instead of
In GitLab 13.0,
sidekiq-cluster was enabled by default and the
sidekiq-cluster under the hood. However, users could control this
sidekiq['cluster'] setting to run Sidekiq directly instead.
Users could also run
sidekiq-cluster separately using the various
sidekiq_cluster[*] settings available in
gitlab.rb. However these features
were deprecated and are now being removed.
Starting with GitLab 14.0,
sidekiq-cluster becomes the only way to run Sidekiq
omnibus-gitlab installations. As part of this process, support for the
following settings in
gitlab.rb is being removed:
sidekiq['cluster']setting. Sidekiq can only be run using
sidekiq_cluster[*]settings. They should be set via respective
sidekiq['concurrency']setting. The limits should be controlled using the two settings
Removing support for using Unicorn as web server
In GitLab 13.0, Puma became the default web server for GitLab, but users were
still able to continue using Unicorn if needed. Starting with GitLab 14.0,
Unicorn is no longer supported as a webserver for GitLab and is no longer
shipped with the
omnibus-gitlab packages. Users must migrate to Puma following
to upgrade to GitLab 14.0.
The Consul version has been updated from
1.9.6 for Geo and multi-node PostgreSQL installs. Its important
that Consul nodes be upgraded and restarted one at a time.
See our Consul upgrade instructions.
Automatically generating an initial root password
Starting with GitLab 14.0, GitLab automatically generates a password for initial
administrator user (
root) and stores this value to
/etc/gitlab/initial_root_password. For details, see the
documentation on initial login.
PostgreSQL 11 and repmgr removal
The binaries for PostgreSQL 11 and repmgr have been removed.
Prior to upgrading, administrators using Omnibus GitLab must:
- Ensure the installation is using PostgreSQL 12
- If using repmgr, convert to using patroni
Redis configuration changes
Two configuration options for Redis were deprecated in GitLab 13 and removed in GitLab 14:
redis_slave_roleis replaced with
redis['client_output_buffer_limit_slave']is replaced with
Redis Cache nodes being upgraded from GitLab 13.12 to 14.0 that still refer to
gitlab.rb will encounter an error in the output of
There was an error running gitlab-ctl reconfigure: The following invalid roles have been set in 'roles': redis_slave_role