bin/runtests - Travis cached database issues

[yvaucher]

I spotted 2 use cases that can case cause trouble right now.

Both can be resolved by dropping the cache, but can leave to false positive or false negative travis builds.

Both affect only the migration testing. It will affect people using migration.yml and changing the odoo/VERSION file.

With the following config in travis:

before_install:
  - if [ "$TRAVIS_PULL_REQUEST" == "false" -a -z "$TRAVIS_TAG" ] ; then export CREATE_DB_CACHE="true" ; fi
script:
  - docker-compose -f $TRAVIS_COMPOSE run --rm -e MARABUNTA_MODE=sample -e MARABUNTA_ALLOW_SERIE=True -e CREATE_DB_CACHE=${CREATE_DB_CACHE} -e MIG_LOAD_VERSION_CEIL=${TRAVIS_TAG} odoo runmigration

1. :timer_clock: Cached DB is not generated on the right time (meaning after a tag)

So you have an extra version in it that can raise issue. (this is typically what happened on some case with 5 digits versions)

master

• commit 1 tag 10.0.1 no cache created (travis fails or no cache setup existed)
• commit 2 add a step in migration.yml for next release 10.0.2 -> CACHED DB named 10.0.1 with step 10.0.2 :skull_and_crossbones:
• commit 3 Travis launch migration.yml restore with step 10.0.2 already installed :bomb:

how to solve it

• Drop cache, relaunch job of tag 10.0.1

TODO fix caching feature

Do the playing of migration.yml in 2 steps 1a. restore dump or 1b. install till previous versions 2. install current version

In the script we should truncate migration.yml setting up the new database for step (1b).

It's not perfect as the code is not exactly to the version it was on tag install. But each steps should still be installable. Thus would be close to creating cache from scratch but still faster and would be fail safe.

2. :face_with_head_bandage: On patched version

We should be looking for a cached DB named after odoo/VERSION thus play the current step. It should use master branch cache, but in case there is no cache on master it will create it's own which might become an issue with multiple commits on a patch branch. Now, the issue that could happen is when merging the patched version into master you might be adding a version in the past, which makes the cache invalid.

• create release-10.1.0 -> deployed on integration then prod
• create release-10.2.0 -> deployed on integration only
• create patch-release-10.1.1
• merge patch into master :bomb:

When merging patch-release-10.1.1 on top of release-10.2.0 we create a new step in the past. Thus cache became invalid. I currently don't see how we could detect that.

how to solve it

Here we need either to:

• drop cache and replay from scratch (manually) or
• drop cache and relaunch tag 10.1.0 so we dropped 10.2.0 then launch our job again. (manually)

TODO fix caching feature

Here the issue is that we need to know which version are installed in which cached DB before restauring any. Thus, we might want to create a manifest file per dump listing all installed versions. Thus, if 10.1.1 is merged on top of 10.2.0, we could do the following steps:

1. Drop cached DB > 10.1.1 that are missing version 10.1.1 (manifest files compared to migration.yml)
2. Restore dump from highest version < 10.1.1 (ie. 10.1.0) or nothing if doesn't exists
3. truncate migration.yml after 10.1.1 (we want to prepare a dump that includes 10.1.1)
4. Run migration till 10.1.1
5. Create cached file
6. Run last migration step 10.2.0