From 7.14 to 8.0

0. Double-check your Git version

This notice applies only to /usr/local/bin/git

If you compiled Git from source on your GitLab server then please double-check
that you are using a version that protects against CVE-2014-9390. For six
months after this vulnerability became known the GitLab installation guide
still contained instructions that would install the outdated, 'vulnerable' Git
version 2.1.2.

Run the following command to get your current Git version:

/usr/local/bin/git --version

If you see 'No such file or directory' then you did not install Git according
to the outdated instructions from the GitLab installation guide and you can go
to the next step 'Stop server' below.

If your Git repositories are in a directory other than /home/git/repositories,
you need to tell gitlab-git-http-server about it via /etc/default/gitlab.
See lib/support/init.d/gitlab.default.example for the options.

6. Copy secrets

The secrets.yml file is used to store keys to encrypt sessions and encrypt secure variables.
When you run migrations make sure to store it someplace safe.
Don't store it in the same place as your database backups,
otherwise your secrets are exposed if one of your backups is compromised.

If you are using Apache instead of NGINX please see the updated Apache templates.
Also note that because Apache does not support upstreams behind Unix sockets you will need to let gitlab-git-http-server listen on a TCP port. You can do this via /etc/default/gitlab.

9. Migrate GitLab CI to GitLab CE/EE

Now, GitLab CE and EE has CI integrated. However, migrations don't happen automatically and you need to do it manually.
Please follow the following guide to migrate your GitLab CI instance to GitLab CE/EE.

10. Use Redis v2.4.0+

Previous versions of GitLab allowed Redis versions >= 2.0 to be used, but
Sidekiq jobs could fail due to lack of support for the SREM command. GitLab
8.0 now checks that Redis >= 2.4.0 is used. You can check your Redis version
with the following command:

redis-cli info | grep redis_version

11. Start application

sudo service gitlab start
sudo service nginx restart

12. Check application status

Check if GitLab and its environment are configured correctly:

sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

To make sure you didn't miss anything run a more thorough check:

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

If all items are green, then congratulations, the upgrade is complete!

2. Restore from the backup

If you have more than one backup *.tar file(s) please add BACKUP=timestamp_of_backup to the command above.

Troubleshooting

"You appear to have cloned an empty repository."

If you see this message when attempting to clone a repository hosted by GitLab,
this is likely due to an outdated Nginx or Apache configuration, or a missing or
misconfigured gitlab-git-http-server instance. Double-check that you correctly
completed Step 5 to install the daemon and
Step 8 to reconfigure Nginx.