Upgrade gitlab 18 to 19 - mattermost deprecation causing failure.

In version 19 of GitLab mattermost has been removed from the omnibus package. The upgrade process checks for mattermost configuration directives and aborts if any are found. Unfortunately these can take some weeding out - particularly when using the https://packages.gitlab.com/gitlab/gitlab-ee apt repository.

Our specific case:

To upgrade:

Do usual checks and backups beforehand.

Check all mattermost configuration options in /etc/gitlab/gitlab.rb are commented out or removed. If they are removed then it is easy to check with grep that nothing has been missed.

Run gitlab-ctl reconfigure to check configuration is ok.

In /etc/gitlab/ run

grep mattermost *

You will probably see an entry from gitlab-secrets.json. If so edit this file and remove the mattermost block:

  "mattermost": {
    "email_invite_salt": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "file_public_link_salt": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "sql_at_rest_encrypt_key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    "register_as_oauth_app": null
  },

At this point the upgrade instructions for the docker version etc. tell you to run gitlab-ctl reconfigure again. Do not do this - the chef recipe will insert the mattermost config back into gitlab-secrets.json and then merge it into the combined configuration. Instead, as per

https://forum.gitlab.com/t/mattermost-blocking-the-upgrade-from-18-to-19/134464/2

delete the nodefile /opt/gitlab/embedded/nodes/<your-fqdn>.json

The initial part of the upgrade complains about this missing, but seems to run ok. Potentially you could instead excise the mattermost bits out of this file.

You should now be able to upgrade gitlab to major version 19, e.g.

apt install gitlab-ee=19.1.2-ee.0

If the upgrade still complains then you might also have to edit /var/opt/gitlab/gitlab-rails/etc/gitlab.yml and remove the mattermost section - will look like:

 mattermost:
   enabled: false
   host:

Once the upgrade is done watch the background migrations as usual.

On one upgrade the process complained about the version of redis running being different from installed. Waited until background migrations had finished then restarted it. Then decided to reboot to double-check everything worked.