An error occurred fetching the project authors.
- 07 Mar, 2017 1 commit
-
-
Sebastien Robin authored
-
- 03 Oct, 2016 1 commit
-
-
Sebastien Robin authored
-
- 27 Sep, 2016 1 commit
-
-
Sebastien Robin authored
-
- 31 Aug, 2016 1 commit
-
-
Sebastien Robin authored
With previous algorithm, work was given to additional test nodes only when: - we were previously below the needed capacity - when another test node was dying Now, as soon as a new test node is added, we move work of overloaded test nodes to idle test nodes. We try to move only test suite using many test nodes to avoid having to wait for building time. This allows to have better distribution of the work with the idea to have more quickly test results. This will avoid cases where we have several testnodes assigned to no work at all. Finally, fixed distribution algorithm to avoid some unfair cases where a test suite might have more test node than another while they both ask for the same number of test nodes.
-
- 01 Jul, 2016 1 commit
-
-
Sebastien Robin authored
Up to now, once all test result lines in draft were processed, test result lines already started where affected to all test nodes. It was designed like this in case the initial affected test node was unable to finish is work (test node or machine could die for various reasons). But having a testnode dying should be rare, thus optimisation should not consider that this happens all the time, even though we must take into account that this could happen. This was leading to cases where a testnode, instead of quiting a test suite to process another was affected a test already affected. So it happened that we loosed one hour of a testnode while it could do much more useful work than repeating the work of another testnode. Thus, consider that testnodes are usually able to process their work, and make testnodes immediately work on another test suite once all tests of a test result are started. Then, run regularly an alarm looking for stuck test to restart them in order to affect work already affected only when required. This change should make the system more reactive when things are working (wich is the majority of time). Not working cases would still finish to work, but in a less reactive way. If we wait urgently for a test result and we see that a test is stuck, there is also possibility to unblock it by hand (if we do not want to wait the alarm).
-
- 18 Mar, 2016 1 commit
-
-
Sebastien Robin authored
-
- 21 Feb, 2016 1 commit
-
-
Kirill Smelkov authored
Both erp5.git and slapos.git were moved to lab.nexedi.com, so it is time to update all links.
-
- 16 Jun, 2015 1 commit
-
-
Sebastien Robin authored
Since we have precision to second in the catalog, we sometimes had the cancelled test result from the previous test disurbing the test_07. By the way, directly filter out cancelled test result with TaskDistributionTool.createTestResult since they should be ignored.
-
- 12 Jun, 2015 1 commit
-
-
Sebastien Robin authored
Live tests was sometimes not working because of data remaining from other tests
-
- 10 Mar, 2015 1 commit
-
-
Gabriel Monnerat authored
-
- 02 Jul, 2014 1 commit
-
-
Jérome Perrin authored
This is in order for tests to have the same id on each test run
-
- 28 Jun, 2014 1 commit
-
-
Sebastien Robin authored
Optimize sorting of list of test suite to be executed by test nodes. We give priority to test suite with older test results. This allows to have test node resources in a more fair way.
-
- 14 Apr, 2014 1 commit
-
-
Benjamin Blanc authored
Conflicts: bt5/erp5_test_result/bt/revision bt5/erp5_test_result/bt/template_document_id_list bt5/erp5_test_result/bt/template_extension_id_list (cherry picked from commit 63c1fc09) Conflicts: bt5/erp5_test_result/TestTemplateItem/portal_components/test.erp5.testTaskDistribution.py bt5/erp5_test_result/bt/revision
-
- 30 Jan, 2014 1 commit
-
-
- 10 Sep, 2013 2 commits
-
-
Arnaud Fontaine authored
ZODB Components: Revert 'Allow to execute runUnitTest for bt5 Test Components' (a771dca4) to fix tests bootstrap. The new syntax to load ZODB Tests Components is: runUnitTest BT_TITLE:TEST_NAME That commit was too adhoc as it was relying upon filesystem to load Tests Components and was not behaving like any other Components (versions was not available and other Components were not importable). At the end, it would have meant that a Test Component ran through runUnitTest and Live Tests (in ERP5 itself) would have behaved differently, thus instead: 1/ Install BT_TITLE dependencies and its test dependencies (new bt property to specify bt to be installed only for tests on a fresh instance). 2/ The site is loaded. 3/ Load the test by importing it like any other Components.
-
Arnaud Fontaine authored
-
- 16 Jul, 2013 1 commit
-
-
Sebastien Robin authored
-
- 05 Jul, 2013 2 commits
-
-
Sebastien Robin authored
-
Sebastien Robin authored
-