Update my GitLab from 7.2.2 to last version

I have installed the new version of gitlab in new server . So How to push all the code residing in old version to latest version?
i.e migrate repositories to new version in one shot

Hi sharmmoh1983,

Sure, I can help you on this, prior to that is it possible for you to tell me the installation type, is it a non-Omnibus installation or Omnibus installation.
If its omnibus installation, few things to be noted before embarking on the Upgrade.

  • The upgrade is a big leap from 7.x to 8.8.0 (latest version) There are a lot of changes between 7.x to 8.8 and so on.

  • Multiple steps are need to upgrade to latest, direct upgrade is not possible.

  • Gitlab backup can be restored on the same version of Gitlab version. Eg: 7.1 backup will go in to 7.1 only, not on 7.2.

  • I recommend you take a backup before you embark on the upgrade from 7.x to 8.8 (latest)

Assuming you are on 7.1, direct upgrade from 7.1 to 8.8 or any 8.x might not be successful, earlier people have faced DB migration failing, to avoid this you need to take a few steps, Please find them below.
Gitlab 7.1 to Gitlab 7.4
Gitlab 7.4 to Gitlab 7.6
Gitlab 7.6 to Gitlab 8.0
Gitlab 8.0 to Gitlab 8.5 (optional , u can skip this step if you like and upgrade from 8.0 to 8.8)
Gitlab 8.5 to Gitlab 8.8
Gitlab 8.8 to Gitlab x.x
Please let me know the version you want after upgrade, accordingly I can post the steps for it.

Reference
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/update/README.md#updating-from-gitlab-66-and-higher-to-the-latest-version
https://docs.gitlab.com/omnibus/update/

Thanks!

Hi Akhliesh

Thanks for your response

It is a non Omnibus installation

I will explain you my complete scenario:

There are two servers where gitlab is installed , one having our current instance with version 7.x.x and having all source code repositories
Second has freshly installed gitlab version 10.X.X

We have configured LDAP authentication on new server as per the current setup

Now we want to move only every repository residing in our current server (7.x.x.) to the new server

So what is the best way to ship every code (repositories) from one server to another ( from 7.x.x. to 10.x.x)

Please let me know what is the safe way to port my current repositories to already installed updated version of gitlab on different server

Also let me know if anything else required to map every file from old version to new already installed version on new system

Hi sharmmoh1983,

Thanks for you reply, i understand your point what you want to know.
I request you to follow the below step to configure you gitlab server to move you gitlab repositories from 7.2.2. to 10.x.x.

First create a empty directory and move all your reposiotries

/var/opt/gitlab/git-data/repositories to /mnt/gitlab/repositories

Make sure the target directory is empty: use a tar pipe
If the target directory /mnt/gitlab/repositories is empty the simplest thing to do is to use a tar pipe. This method has lowoverhead and tar is almost always already installed on your system.However, it is not possible to resume an interrupted tar pipe: ifthat happens then all data must be copied again.

#As the git user

tar -C /var/opt/gitlab/git-data/repositories -cf - – . |
tar -C /mnt/gitlab/repositories -xf -

Tar pipe to another server you can also use a tar pipe to copy data to another server. If your ‘git’ user has SSH access to the newserver as ‘git@newserver’, you can pipe the data through SSH.

#As the git user

tar -C /var/opt/gitlab/git-data/repositories -cf - – . |
ssh git@newserver tar -C /mnt/gitlab/repositories -xf -

If you want to compress the data before it goes over the network (which will cost you CPU cycles) you can replace ssh with ssh -C.

The target directory contains an outdated copy of the repositories: use rsync

If the target directory already contains a partial / outdated copy of the repositories it may be wasteful to copy all the data again with tar. In this scenario it is better to use rsync. This utility is either already installed on your system or easily installable via apt, yum etc.

#As the 'git' user

rsync -a --delete /var/opt/gitlab/git-data/repositories/.
/mnt/gitlab/repositories

The /. in the command above is very important, without it you can
easily get the wrong directory structure in the target directory.
If you want to see progress, replace -a with -av.

Single rsync to another server

If the ‘git’ user on your source system has SSH access to the target server you can send the repositories over the network with rsync.

#As the 'git' user

rsync -a --delete /var/opt/gitlab/git-data/repositories/.
git@newserver:/mnt/gitlab/repositories

Thousands of Git repositories: use one rsync per repository

Every time you start an rsync job it has to inspect all files in the source directory, all files in the target directory, and then decide what files to copy or not. If the source or target directory has many contents this startup phase of rsync can become a burden for your GitLab server. In cases like this you can make rsync’s life easier by dividing its work in smaller pieces, and sync one
repository at a time.

In addition to rsync we will use GNU Parallel. This utility is not included in GitLab so you need to install it yourself with apt or yum. Also note that the GitLab scripts we used below were added
in GitLab 8.1.

** This process does not clean up repositories at the target location that no longer exist at the source. ** If you start using your GitLab instance with /mnt/gitlab/repositories, you need to run gitlab-rake gitlab:cleanup:repos after switching to the new repository storage directory.

Parallel rsync for all repositories known to GitLab

This will sync repositories with 10 rsync processes at a time. We keep track of progress so that the transfer can be restarted if necessary.

First we create a new directory, owned by ‘git’, to hold transfer logs. We assume the directory is empty before we start the transfer procedure, and that we are the only ones writing files in it.

#Omnibus

sudo mkdir /var/opt/gitlab/transfer-logs
sudo chown git:git /var/opt/gitlab/transfer-logs

#Source

sudo -u git -H mkdir /home/git/transfer-logs

We seed the process with a list of the directories we want to copy.

#Omnibus
sudo -u git sh -c ‘gitlab-rake gitlab:list_repos > /var/opt/gitlab/transfer-logs/all-repos-$(date +%s).txt’

#Source

cd /home/git/gitlab
sudo -u git -H sh -c ‘bundle exec rake gitlab:list_repos > /home/git/transfer-logs/all-repos-$(date +%s).txt’

Now we can start the transfer. The command below is idempotent, and the number of jobs done by GNU Parallel should converge to zero. If it does not some repositories listed in all-repos-1234.txt may have been deleted/renamed before they could be copied.

#Omnibus

sudo -u git sh -c ’
cat /var/opt/gitlab/transfer-logs/* | sort | uniq -u |
/usr/bin/env JOBS=10
/opt/gitlab/embedded/service/gitlab-rails/bin/parallel-rsync-repos
/var/opt/gitlab/transfer-logs/success-$(date +%s).log
/var/opt/gitlab/git-data/repositories
/mnt/gitlab/repositories

#Source

cd /home/git/gitlab
sudo -u git -H sh -c ’
cat /home/git/transfer-logs/* | sort | uniq -u |
/usr/bin/env JOBS=10
bin/parallel-rsync-repos
/home/git/transfer-logs/success-$(date +%s).log
/home/git/repositories
/mnt/gitlab/repositories

Parallel rsync only for repositories with recent activity

Suppose you have already done one sync that started after 2015-10-1 12:00 UTC. Then you might only want to sync repositories that were changed via GitLab after that time. You can use the ‘SINCE’ variable to tell ‘rake gitlab:list_repos’ to only print repositories with recent activity.

#Omnibus

sudo gitlab-rake gitlab:list_repos SINCE=‘2015-10-1 12:00 UTC’ |
sudo -u git
/usr/bin/env JOBS=10
/opt/gitlab/embedded/service/gitlab-rails/bin/parallel-rsync-repos
success-$(date +%s).log
/var/opt/gitlab/git-data/repositories
/mnt/gitlab/repositories

#Source

cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:list_repos SINCE=‘2015-10-1 12:00 UTC’ |
sudo -u git -H
/usr/bin/env JOBS=10
bin/parallel-rsync-repos
success-$(date +%s).log
/home/git/repositories
/mnt/gitlab/repositories

When we move repositories from one server to another server three scenarios will come
a) the target directory is empty.
b) the target directory contains an outdated copy of the repositories, and
c) how to deal with thousands of repositories.

And the above step is only focus on first scenario that is a) the target directory is empty.
If you want to perform the other to scenarios then please refer the below link:

Thanks!

Hi Akhilesh

We tried to tar and untar single group (having projects) from old server and placed in new server but it is not visible in gitlab UI

Project: eai-tools
But when we created eai-test group through UI and imported repository in the group we can see projects

This approach is very tedious so lets us know what we are missing

drwxrwx— 4 git root 43 Mar 27 11:18 eai-test
drwxrwx— 6 git root 98 Mar 27 11:23 eai-tools