Re: [boost] Boost CI Infrastructure
2. Standard "CI script"[2] that is used by all the C/C++ projects instead of each projects doing their own thing.
Out of curiosity, would this allow me to run my integration tests, which require to set up a DB instance and load data before running tests? Regards, Ruben
Ruben Perez
2. Standard "CI script"[2] that is used by all the C/C++ projects instead of each projects doing their own thing.
Out of curiosity, would this allow me to run my integration tests, which require to set up a DB instance and load data before running tests?
There is built-in support for installing system packages (currently for Debian and Fedora or alike), so you would be able to install the database (see [1] for an example of a package that does something like this). For loading data you would need a hook into this CI script. While this is not yet supported, we do have support for enabling/disabling various steps in this script. For example, this mechanism can be used to enable optional binary distribution package generation (Debian/Fedora/archive) and their upload. It would be pretty natural to extend this mechanism to allow pre/post hooks for each step. While the hook will most likely just execute whatever program you have specified (so can be shell/Python/PowerShell/etc), the hard part here (at least for the user) will be to come up with something portable that can also be executed on Windows. But we have some ideas here: seeing that we have a portable scripting language for ad hoc recipes/rules, we could make it an option for writing hooks, so you will, at a minimum, be able to write a thunk that decides what to execute on each platform. We will most likely implement all of this for the next version (0.17.0) since we need this functionality ourselves (also for DB-related testing). [1] https://github.com/build2-packaging/SimpleBLE/blob/master/libsimpleble/manif...
There is built-in support for installing system packages (currently for Debian and Fedora or alike), so you would be able to install the database (see [1] for an example of a package that does something like this).
Doing integration testing like this is extremely fragile. The approach I've found best (at least in my case) is running your DB service as a Docker image.
participants (2)
-
Boris Kolpackov
-
Ruben Perez