Closed soininen closed 7 months ago
Would it make sense to add SpineInterface tests to spinedb_api
GitHub actions as well?
I think so, they are also kinda quick...
Also, I have broken toolbox after modifying spine_engine so maybe we can also add toolbox tests to spine_engine CI workflow?
I have now added Toolbox unit and execution tests to DB API repository. The test matrix includes only Linux + Python 3.8 which should be sufficient to see if something gets broken. The action is run on each push and we use the 0.8-dev
branch on Toolbox. This might cause an issue when we are working on both repositories at the same time. I guess in that case a failing Toolbox unit test can be ignored and the author of the PR is responsible of running Toolbox tests manually.
I am not entirely happy that this introduces a "dependency" from DB API to Toolbox. The other option would have been to make pushes to DB API repository trigger GitHub actions in Toolbox repository but that seemed trickier to implement. It could be done later, if we feel like it, though.
For now, lets see how this works. If we find it useful, we can consider adding similar tests for SpineInterface (their tests do no pass at the time of writing, anyway) or SpineEngine -> Toolbox.
Toolbox uses
spinedb_api
heavily. It is quite possible that a change inspinedb_api
breaks something in Toolbox even though thespinedb_api
unit tests pass. We could add Toolbox unit tests as part ofspinedb_api
GitHub actions so there would be a check before PRs get merged to master. There is probably no need to run the entire test system matrix (Windows, Linux, all supported Python versions). Running the tests on a single system should suffice to give an early warning if something is broken. On that note, tests on Linux are generally faster.