Skip to content

Move gitlab instance to official gitlab omnibus docker image

Use official Docker Image

We (Heidelberg Dune Developers) would like to switch to the official omnibus docker image for hosting this gitlab instance. In the following text we try to explain why and we would be happy to get some input from you :)

Current State

If we are not using the official docker image, you might wonder what we use instead? At the moment we use docker images created by this project:

https://github.com/sameersbn/docker-gitlab

In order to suite our needs Steffen patched (you could even say forked) the project and changed lots of stuff. The reasons for patching are:

  • We want to apply custom hooks (whitespace hook, merge request formatting)

  • We run two gitlabs on our server, the dune gitlab and our group internal gitlab. This needs some adjustment of the project.

  • The reason to use this image in the first place is that it is really flexible since you have control over all the services and the whole setup.

Why Change Anything?

The main reason to change to the official docker image is twofold:

  1. Updating the fork of the above problem is a real pain. Gitlab has one new big release every month and 2-4 patch releases per month. Steffens adjustments often lead to merge conflicts. This means changing to the official image will:

    a) Save us lots of time since updating the official docker image is trivial.

    b) Updating the official image is a lot less error prone and in case of trouble it is possible to ask for help on the gitlab issue tracker.

  2. In the near future we want to hand over the gitlab to the new software center that will be created at IWR Heidelberg. For this migration we will have to give up our complicated setup anyway.

What are the Risks/Problems?

Going to the official docker image means:

  1. The safest way to migrate is creating a backup through the gitlab backup facility while gitlab is not running. This means our gitlab will be down during the whole migration period. We already did that for our group internal gitlab, so we know what to do but for the dune-gitlab this will take some hours. If we include testing the new instance before it is brought back online we expect around 1-2 days of downtime.

  2. If the migration fails we can go back to the old one in the exact state it was before the migration started.

  3. We already switched to the official docker image for our group internal gitlab and everything worked fine but it is of course impossible to predict if there will be unforeseen problems.

  4. One thing that was not properly tested with our group internal gitlab is the registry but we are confident that it should be possible to solve all issues that might show up.

  5. In our current gitlab we have custom generated merge messages. We will lose this feature in the new setup.

  6. It is possible to apply hooks (eg whitespace hook) in the new setup. But: Tests during the migration of our group internal gitlab showed that our hook is not working anymore. This bug is also affecting our current gitlab. We have mostly fixed it but our gitlab does not yet use the new version. This is unrelated to the migration and will be another issue.

Proposed Steps

If we come to the conclusion that we want to migrate our gitlab we propose the following steps:

  1. Decide on a date for migration and communicate to developers and users.

  2. During the migration period the gitlab will be down. It should be possible to show a meaningful error message on https://gitlab.dune-project.org/.

  3. We do the migration.

  4. After migration we could start the gitlab under the address of our group internal gitlab. This can be used for testing without risking that people do actual software development during the testing period. Everyone interested could participate in this step, just note that all things you do on the test instance would be lost if we go back to the old gitlab before the migration.

  5. If everything works fine we can finish migration by hosting it on https://gitlab.dune-project.org/. If it didn't work out we could go back to the exact state before migration started.

Thanks for the attention! If you have any questions or insights we would be glad to hear them. Maybe there are some issues or topics we completely missed.