Before SlapOS and concept of a distributed cloud connected over a mesh IPv6 network called re6stnet we used to have manually setup few boxes that had all required components installed system wide by respective linux distribution package manager. Even though this approach worked it had few downsides:
The architecture of test node contains following components:
Test nodes doesn't know in advance on which testsuite they are going to
work on. Therefore every test node is defined with the url of a
distributor. The test node will call "startTestSuite" on the distributor
and it will get all needed parameters to work on one or many test suites.
The first time a test node calls startTestSuite, distributor is
going to look if this test node already exists. If not, then it will be
created under test node module.
From time to time an alarm at distributor
looks at all defined test suites and available test nodes and distribute
the work to do. This alarm avoid moving test suite from a test node to
another uselessly. In the same time, this alarm is checking for all test
node that seems dead (10 hours without sending message) and invalidate
them. Like this test suite allocated to a dead test node will be moved
to another test node automatically.
Let's say we have 2 testing nodes daemon (A and B) running on two
different computers. Each daemon is doing checkout or update of
repositories. Since A and B can run with several minutes or even more of
interval, distributor needs to make sure that both A and B are testing
same revision. Therefore testnode A (assuming no test is already
started) will do :
And then testnode B will do (running a little bit after testnode A):
Like this we are sure that all computers running the same test suite will be synchronized.
We manage to reduce a lot time needed to setup test node machines, we reused a lot of SlapOS code, principles and recipes to setup ERP5 inside a test node which improved general ERP5's own setup recipes, we learned how to build and compile our own required packages in order to create isolated and safe environment inside any major Linux distribution. Last but not least we simplified a lot developers' life, created procedures to follow and implied strict rules for contributing to ERP5: if your own branch do not pass test suites you are not allowed to merge your changes inside ERP5 master branch. This rule itself improved quality of ERP5 code.