I don't agree. A lot of features seem half-baked. The public Gitlab issues are filled with features that don't seem to work or are poorly understood because of their spare or incomplete documentation. These issues often just languish until the gitlab bot closes them for inactivity. However the only inactivity for many of these is just Gitlab's failure to respond.

everything works great on gitlab, until the moment you had to migrate.

Landmine experience in issue lists

Hi, Community Advocate from GitLab here. Could you please reference what issues you are experiencing? We'd love to follow up on it.

Also, if you want to write the details, it would be great to open an issue https://gitlab.com/gitlab-org/gitlab-ce/issues. Thanks in advance.

Hi,

https://gitlab.com/gitlab-org/gitlab-ce/issues/27217

Something like this. When I fixed the VERSION manually, there are other errors, as expected.

However the peculiar thing is the errors are not idempotent. Somethings there's some postgres wrong column error, other times it says you can't import the project because you can't have hyphens in project names. (which I don't)

Migration is hard, considering everything can be linked in Gitlab.

One, having to come from the same version.

Two, having to connect to the same block storage in exactly the same way to make everything work.

I just want to upload a backup that gitlab makes, and upload that somewhere (anywhere) to restore from that one tarball, regardless of where I’ve decided to host my current instance or data (or indeed, if I’ve decided to use block storage again or not).

Thanks for the feedback.

1. Yes, you have to restore a backup on exactly the same version of GitLab and then upgrade that version. If you restore it to a different version the database scheme isn't correct.

2. You can restore a GitLab backup anywhere https://docs.gitlab.com/ee/raketasks/backup_restore.html as long as it is the same version. I think the output is a single file.

Thanks for the response.

1. Gitlab is able to migrate up to a new version, so is there anything preventing it from getting up to a certain (older) version before running the last few migrations after restore?

If I set up a new instance it’s generally one or two minor versions higher than the old instance.

2. I swear I restored from my omnibus installation to Helm based gitlab and lose all my uploads and registry images. Cannot see from the docs why that would happen any more though.

Maybe it was the opposite, with me restoring the backup to the same block storage devices, and gitlab hiccuping on the fact that all the files it wanted to restore were already there.

We've opened https://gitlab.com/charts/gitlab/issues/1015 to discuss this comment. I don't believe the db migrations are what are holding us back, as much as the other parts of the backup/restore.

For number 2, that sounds unexpected, and we would love for you to give us more details. https://gitlab.com/charts/gitlab/issues

1. I'm not sure and will ask.

2. It might be that this wasn't supported yet in the Helm chart at that time, I'm not sure.

Thanks for the feedback.