qwat / qwat-data-model

TEKSI Water module (project QWAT) - PostgreSQL / postgis Datamodel
https://www.teksi.ch
23 stars 25 forks source link

travis PUM tests don't apply all deltas from 1.0.0 but from 1.3.0 #211

Closed haubourg closed 6 years ago

haubourg commented 6 years ago

We are trying to add a new version 1.3.0 and it fails because only delta > = 1.3.0 are applied to qwat_tes when travis runs pum test-and-upgrade.

We do that in the PR https://github.com/qwat/qwat-data-model/pull/210

See the build log here https://travis-ci.org/qwat/qwat-data-model/builds/309557000#L2836

@marioba what are we doing wrong here? maybe qwat_test restore misses info table metadata ?

marioba commented 6 years ago

I don't understand why at line 2780 in the travis log, before the test-and-upgrade, there is a pum baseline -p qwat_comp -t qwat_sys.info -d $TRAVIS_BUILD_DIR/update/delta/ -b $VERSION

haubourg commented 6 years ago

We just changed that now to let all the script (init_qwat, upgrade_db and travis) get current version by reading the /system/CURRENT_VERSION.txt. But we had the same issue without that. Let me check if I hardcode it to 1.3.1

haubourg commented 6 years ago

no difference with the hardcoded 1.3.1

haubourg commented 6 years ago

I tested locally and i baselined the qwat prod restored from the update/delta/qwat_1_0_0_dump.dump and it seems to work. Maybe that's all what is missing ?

haubourg commented 6 years ago

@marioba Does pum test-and-upgrade assume that the prod database is baselined? if it is not, what's the expected behavior?

marioba commented 6 years ago

In your case the prod db is baselined to 1.0.0 see https://travis-ci.org/qwat/qwat-data-model#L697 If pum try to upgrade a db without baseline it should return an error.

haubourg commented 6 years ago

Ok, so I have no clue why it is not running delta from 1.0.1 but from 1.3.0... any help welcome

marioba commented 6 years ago

The init_qwat.sh script will set the baseline to 1.3.0 on prod https://github.com/qwat/qwat-data-model/blob/9ceaa568b60c5439a4fc2b1974b58d61fce9e48b/init_qwat.sh#L261 when you create the comp db...

haubourg commented 6 years ago

Oh good catch Mario. But removing it means the init_qwat script is not sufficient for someone to start correctly a new fresh QWAT install. @sylvainbeo any idea how to solve both incompatible requirements ? Maybe travis should "clear" thebaseline made by the init_qwat.sh?

sylvainbeo commented 6 years ago

@haubourg We should add a param to init_qwat.sh. By default, if no param is given, the baseline is applied with the current version. Else 1.0.0 is applied. Example:

./init_qwat.sh --first-baseline

sylvainbeo commented 6 years ago

Done. Please have a look:

https://travis-ci.org/qwat/qwat-data-model/builds/309713815

sylvainbeo commented 6 years ago

There's still one problem, when pushing the releases :

Traceback (most recent call last): File "./.deploy/create_release.py", line 170, in <module> main() File "./.deploy/create_release.py", line 128, in main 'Authorization': 'token {}'.format(os.environ['GH_TOKEN']) File "/home/travis/virtualenv/python3.5.3/lib/python3.5/os.py", line 725, in __getitem__ raise KeyError(key) from None KeyError: 'GH_TOKEN'

sylvainbeo commented 6 years ago

@haubourg ^

haubourg commented 6 years ago

@sylvainbeo yep, I filed this for Matthias https://github.com/qwat/QWAT/issues/241

m-kuhn commented 6 years ago

It shouldn't try to deploy in pr. That's just a cosmetic issue and can be ignored for now.

haubourg commented 6 years ago

both issues are solved, closing. Thanks a lot to all of you