4.1 KiB

Raw Blame History

stage	group	info
Systems	Distribution	To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments

GitLab 17 changes

DETAILS: Tier: Free, Premium, Ultimate Offering: Self-managed

This page contains upgrade information for minor and patch versions of GitLab 17. Ensure you review these instructions for:

Your installation type.
All versions between your current version and your target version.

For more information about upgrading GitLab Helm Chart, see the release notes for 8.0.

17.1.0

Bitbucket identities with untrusted extern_uid are deleted. For more information, see issue 452426.
The default changelog template generates links as full URLs instead of GitLab specific references. For more information, see merge request 155806.
Git 2.44.0 and later is required by Gitaly. For self-compiled installations, you should use the Git version provided by Gitaly.

17.0.0

You should migrate to the new runner registration workflow before upgrading to GitLab 17.0.

In GitLab 16.0, we introduced a new runner creation workflow that uses runner authentication tokens to register runners. The legacy workflow that uses registration tokens is now disabled by default in GitLab 17.0 and will be removed in GitLab 18.0. If registration tokens are still being used, upgrading to GitLab 17.0 will cause runner registration to fail.
Gitaly storages can no longer share the same path as in this example:
```
gitaly['configuration'] = {
  storage: [
    {
       name: 'default',
       path: '/var/opt/gitlab/git-data/repositories',
    },
    {
       name: 'duplicate-path',
       path: '/var/opt/gitlab/git-data/repositories',
    },
  ],
}
```
In this example, the duplicate-path storage must be removed or relocated to a new path. If you have more than one Gitaly node, you must ensure only the corresponding storage for that node is listed in that node's gitlab.rb file.

If the storage is removed from a node's gitlab.rb file, then any projects associated with it must have their storage updated in the GitLab database. You can update their storage using the Rails console. For example:
```
$ sudo gitlab-rails console
Project.where(repository_storage: 'duplicate-path').update_all(repository_storage: 'default')
```

Linux package installations

Specific information applies to Linux package installations:

The binaries for PostgreSQL 13 have been removed.

Prior to upgrading, you must ensure your installation is using PostgreSQL 14.

Non-expiring access tokens

Access tokens that have no expiration date are valid indefinitely, which is a security risk if the access token is divulged.

When you upgrade to GitLab 16.0 and later, any personal, project, or group access token that does not have an expiration date automatically has an expiration date set at one year from the date of upgrade.

Before this automatic expiry date is applied, you should do the following to minimize disruption:

For more information, see the:

4.1 KiB Raw Blame History