Refuse to install on 7.x and older

This is to prevent CI upgrade trouble with people accidentally going from 7.x to 8.1.

We can detect the pre-update version with this scriptlet I think:

awk 'NR == 1 { print $2}' /opt/gitlab/version-manifest.txt

So in the pre-install script of 8.1 (and after) we could abort if the version starts with 6. or 7..

cc @marin

👍

👍

Please ensure this only affects people actually using CI.

@sytses that would be hard

@jacobvosmaer Since the vast majority of users are not using CI it would be great not to break the upgrade process for them I think.

@jacobvosmaer can we check for build files being present or something like that?

We can check if certain services exist and act according to that.

What if the user had GitLab 7.10 on server A and GitLab CI 7.10 on server B. How does a preinstall script that runs on server A detect that there was a GitLab CI server somewhere else?

Keep in mind that if the user upgrades from GitLab 7.10 to GitLab 8.5 (making up 8.5, it does not exist yet) they may end up with their GitLab DB in a state where they can no longer import CI data, and also no way to roll back. They may only find out a day later, when trying to upgrade their GitLab CI server, that they need to migrate their CI data.

@jacobvosmaer Good point, can we detect if there are GitLab CI hooks configured for any project?

@sytses perhaps, but my gut feeling is it would be expensive (loading the Rails app) and fragile (we cannot count on the database being available when the apt/rpm preinstall script runs).

To be frank, saying 'in 8.0 we allow ourselves to really break things' and '8.0 should be an upgrade you can skip over' feels like having your cake and eating it too.

@jacobvosmaer it might be expensive but I assume we only have run this migration (check for pre 8.0 CI and abort if detected) in GitLab 8.1. Let's see if we can make it robust.

@marin @dzaporozhets any idea's for a robust check if GitLab 7.x and earlier was using CI somewhere? Maybe using a database migration that borks if it finds a GitLab CI hooks configured for any project?

@sytses no I am talking about a check that will run in all future GitLab packages. People may be on 7.14 now and for whatever reason not decide to upgrade until one year from now. This is something we see with customers in corporate environments. That is why I am proposing a simple mechanism: if you upgrade from 7.x to 8.x or higher, you must touch 8.0. If you are upgrading from 7.x to 9.x or higher, you must touch 8.0 and 9.0. Etc.

@jacobvosmaer @sytses We could just ask the user?

• User installs the new package
• We detect if the user is upgrading from a package prior to 8.x
• We print a message: "Detected upgrading from version < 8.x. If you have GitLab CI you must upgrade to 8.0 first. Do you have GitLab CI configured? [YES/NO] "
• User writes YES, we abort and print a message about having to upgrade to 8.0
• User writes NO, we continue

Something to that extent, we can fine tune the messages.

Yes/no prompts during a package installation are very annoying. Not sure if we should go there.

@jacobvosmaer Isn't that the point with this issue? Be annoying so users understand they might break stuff if they ignore the warnings?

@marin sure. I just think it is better to be annoying in a non-interactive way.

@jnijhof , as someone with Debian packaging experience, what do you make of the solutions we are proposing here? To recap, the problem is that the CI migration only works on 8.0 and we want to avoid people getting stuck on a higher-than-8.0 GitLab version while upgrading and losing their CI data.

@jacobvosmaer I proposed to put it in a migration that ships with 8.1. Wouldn't that mean it runs from all future packages?

@sytses interesting idea, a well-placed migration in 8.1 could probably catch it. I am not sure how 'rake db:migrate' does rollbacks, we should probably make sure it fails as early as possible.

It is not 100% clear to me though how to do it with a migration. It would allows us to see if CI is enabled or not. But what we want to prevent is going from 7.x or older to 8.1 or higher. How does the migration see we are coming from 7.x or older?

How does the migration see we are coming from 7.x or older?

@jacobvosmaer database store list of migrations that already completed. If we don't have one of 8.0 migrations in this list - it means we are updating from 7.x

@dzaporozhets I don't understand. That list does not show when migrations ran, just whether they ran.

Installation is at 7.5. Starts upgrade to 8.1. By the time we hit 8.1 migrations, all 8.0 migrations have been completed.

@jacobvosmaer yes you are right. I was confused thinking about rake task

8.1 is about to go out. What do we do about this now?

Concluded to put a warning for CI users to first upgrade to 8.0 in the next few release announcements. We don't want to inconvenience the great majority of people that are not using CI. Also, build information is pretty fungible, not a huge problem to start over.

I've added https://gitlab.com/gitlab-com/www-gitlab-com/commit/74a44554a24bc8d1d2159fb63d2f385aaff02928 and also added it to the template https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1049

Status changed to closed