[ADD] initial PoC for tests for OpenUpgrade

[hbrunn]

this is a PoC for the scenario described in https://odoo-community.org/groups/contributors-15/contributors-41651?mode=date&date_begin=2016-06-01&date_end=2016-07-01, don't merge (yet)

[pedrobaeza]

The problem I see is that we are only going to test:

• The correct run of the script.
• The checks we want to incorporate, based only in what we figure that we have to migrate

But we are not going to know exactly if the migration is totally correct. These tests can create the false sensation of correct migration even if we don't include any assert.

Anyway, having this clear in documentation, it's a good step to avoid some running issues.

[hbrunn]

...and we can (and should) also include measuring coverage, and at the end, only merge stuff which doesn't decrease coverage

[StefanRijnhart]

🌟 🌟 🌟

Try

postgresql: "9.4"

[hbrunn]

I'm trying to find the reason for https://travis-ci.org/OCA/OpenUpgrade/builds/136356675#L503, which is weird, because both https://github.com/OCA/OpenUpgrade/blob/9.0/openerp/addons/base/migrations/9.0.1.3/post-migration.py#L119 and https://github.com/OCA/openupgradelib/blob/master/openupgradelib/openupgrade.py#L1140 look correct. If you have any ideas, let me know

[hbrunn]

looks like OCA/openupgradelib@e748410 is missing from the openupgradelib travis uses. Will have a look what's going on here.

[pedrobaeza]

It seems there has no been another release in PyPi with latest changes of openupgradelib.

[pedrobaeza]

I'm going to make another release.

[hbrunn]

@pedrobaeza thanks, the new release surely makes sense. But for the tests, I'll rewrite .travis.yml to pull the git version of openupgradelib in order to have the latest fixes in there. Especially at the start of the version, we'll probably add stuff and then having to release basically every commit will become annoying.

[pedrobaeza]

@hbrunn, OK, you're right about that point.

[pedrobaeza]

You can install directly with pip: http://stackoverflow.com/questions/20101834/pip-install-from-github-repo-branch

[coveralls]

Changes Unknown when pulling 54edfd62a42059e796ddf0e8742b1549c7a7927c on hbrunn:9.0-tests into * on OCA:9.0*.

[coveralls]

Changes Unknown when pulling f6af3b59f407724907db689c6134d4577d9df538 on hbrunn:9.0-tests into * on OCA:9.0*.

[hbrunn]

@pedrobaeza @StefanRijnhart now it's the way I want it, please review

[coveralls]

Changes Unknown when pulling 6de5396 on hbrunn:9.0-tests into * on OCA:9.0*.

[StefanRijnhart]

Awesome! And it's green. 👍 👍 👍

[hbrunn]

I see three thumbs up, so I'll merge

[hbrunn]

kidding, but thanks for your enthusiasm ;-)

[pedrobaeza]

Is the coverage information correct? How do you measure this coverage?

[hbrunn]

@pedrobaeza it only looks at the migration scripts themselves: https://github.com/OCA/OpenUpgrade/pull/506/files#diff-6f1f859c6ca5c4cae7310924786cf661R7

[legalsylvain]

Hi,

Well first 💯 👍 for this work (*) ! This a good step forward to improve Openupgrade.

A suggestion :

• What about generating DB dynamicaly, based on an OCB instance created each time ?

Pro :

• we could install only "upgradable" module. If lunch is not ported, no need to install it. -> less time during upgrade / update process
• if something changes in OCB / 8.0, maybe the migration will no longer works, and we could detect it (theoritical case maybe ...)
• no need for Therp BV to host and maintain db https://doc.therp.nl/openupgrade/databases/for/9.0
• maybe we could quickly patch OCB / 8.0 branch if there a bug in a demo data that makes the upgrade fail

Cons :

• more time to generate db
• other ?

And a question : I remember that for previous migration, it was not possible to run an openupgrade on a db with demo data but I don't remember why. Why it is now possible from 8.0 -> 9.0 ?

kind regard.

(*) 103 thumbs : time to merge... ;-)

[pedrobaeza]

👍 Merging then

[hbrunn]

@pedrobaeza thanks for merging

@legalsylvain the time thing is crucial: We only have 50 minutes, then travis will kill the job. Now doing nearly nothing it costs 10 minutes, so I fear we'll get timing problems anyways with a growing amount of modules.

Therp hosting the DB images was now the simplest choice, sooner or later I'll ask the OCA to do so - also makes more sense because then more people have access to it. Or just on github, weird I didn't think of that before.

[legalsylvain]

@hbrunn Thanks for the explanation. (and again for this improvement).