Hi, i was asking to myself if it was possible to activate push mirroring from a gitlab v.11.7.4 to a gitlab v.18.0.1, in fact in my case i use gitlab just as a centered repository (branch, commits and tags). My idea was to migrate from gitlab v.11.7.4 hosted in CentOS version that wil be deprecated soon, to a gitlab v18.0.1 docker container hosted in a Debian 12 server. So my idea was to:
- create the container with gitlab v11.7.4 (the same of the one in CentOs)
- create a complete backup of the gitlab v.11.7.4 hosted in the CentOS
- restore the backup in the gitlab v.11.7.4 containerized hosted in the Debian 12
- update step by step following the official upgrade path tool of gitlab the gitlab v.11.7.4 hosted in Debian 12 until we arrive to v.18.0.1
When we correctly updated we can set up the push mirroring fron v.11.7.4 to v.18.0.1 for all the repositories and force the push mirroing.
I tested that and it work but i don’t know if there could be some complicances with massive pushes or a lot of repositories to mirror.
Of course the Debian 12 machine will not be acceccible by anyone until the end. The people will continue to push on the v.11.7.4 hosted in CentOS and at the end of the container’s updates in the Debian 12 machine we will set the push mirroring so there will be no problems of divergences between the upstream and downstream repositories.
You don’t need to push all the code, when doing the backup/restore you will get all your stuffs back.
Just do the backup, and use any other up-to-dated distro.
Use Podman/Docker to pull v11.7.4 and restore the backup.
Do the migration path to upgrade your Instance.
In the end, decide if you will keep using Container, if isn’t the case, do a new backup from the upgraded instance, and restore it on a dedicated distro.
You don’t need push the code in any case, only if you want create a new pristine Instance and import the group/projects from the old instance, you can use Direct Transfer for that, or if only code is important, you can just use your desktop as a proxy:
- Create the project in the new instance
- Clone the repo from old instance.
- On the cloned project, add other remote, like this,
git remote add upstream url_new_repo
- Do a
git push upstream --all --force and git push upstream --tags --force.
Thank you for your response, but my idea was to use push mirroring because can garantee to me 0 downtime because the dev team need to continue to push during the upgrade path. When we finished the upgrade path and we forced all the push mirroring we have the same gitlab data but in a gitlab v.18.0.1 on a docker container in Debian 12. From now we can switch off the old gitlab hosted on CentOS and send a comunicate to all the developer to change the remote origin of the local working copy that they have. This is the only moment where there is the swicth and a little downtime in which the dev team need to change the remote origin.
I don’t know if is clear, if there is something that you don’t understand say to me
.
Thank you 