1. 24 Apr, 2019 1 commit
    • test result: immediately redraft test result line on task failure · fe3bf27f
      Right now we have this scenario:
      - test result line is started
      - sometimes, runTestSuite fails (like timeout), failure is reported
        but test result line remains started (we don't know yet which
        line is associated with testnode)
      - when a test result line is "started" since more than 4 hours,
        test result line is redrafted
      - test can be reexecuted
      Speed up by removing the need of waiting alarm, by knowing which
      test result line is executed by which test node, and by redrafting
      immediately the test result line on test node failure
      Sebastien Robin committed
  2. 12 Apr, 2019 2 commits
  3. 04 Sep, 2018 1 commit
  4. 03 Nov, 2017 1 commit
  5. 01 Jun, 2017 1 commit
  6. 21 Apr, 2017 1 commit
  7. 18 Apr, 2017 2 commits
    • Link Test Result Node with Test Node · 718c995a
      This link allows to navigate from Test Result via its Test Result Node
      to Test Node and distributor related to given Test Result.
      Note: It happens only, if client will do subscribeNode before calling
      Łukasz Nowak committed
    • Allow to stop draft test results · 39678eb9
      This is accompanying commit to "erp5_test_result: stop affecting last
      remaining tests to all test nodes", where alarms redrafts running tests
      for long running nodes.
      In case of very long running test nodes, to which support is introduced
      in this work, it is acceptable situation that test will get redrafted
      and shall be stopped.
      Łukasz Nowak committed
  8. 03 Mar, 2017 1 commit
  9. 03 Oct, 2016 1 commit
  10. 01 Jul, 2016 1 commit
    • erp5_test_result: stop affecting last remaining tests to all test nodes · 8c90e61c
      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).
      Sebastien Robin committed
  11. 16 Jun, 2015 1 commit
    • test_result: fixed random unit test failure · 2063027f
      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.
      Sebastien Robin committed
  12. 08 Nov, 2014 1 commit
    • use fulltext search in title and description. · d47df833
      * to quickly setup catalog_full_text table, you can use the following SQL.
        REPLACE INTO catalog_full_text SELECT uid, title, description FROM catalog;
      * non fulltext queries like '=abc', '>abc', '%abc%' are supported.
      * now erp5_full_text_mroonga_catalog is used for unit tests thus I recommend using it instead of erp5_full_text_myisam_catalog.
      * to migrate existing MyISAM full_text table into Mroonga, you can use the following SQL.
        ALTER TABLE full_text DROP KEY SearchableText,
          ENGINE = mroonga,
          ADD FULLTEXT KEY SearchableText (`SearchableText`) COMMENT 'parser "TokenBigramSplitSymbolAlpha"';
      * fulltext search score is no longer provided as (column_name) but now provided as (column_name)__score__.
      * (category)_title, like source_title, related keys are automatically generated. (category)_description keys as well.
      Kazuhiko Shiozaki committed
  13. 16 Oct, 2014 2 commits
  14. 17 Aug, 2014 1 commit
  15. 02 Jul, 2014 1 commit
  16. 15 Apr, 2013 1 commit
  17. 20 Feb, 2013 1 commit
  18. 23 Jan, 2013 1 commit
  19. 14 Jan, 2013 2 commits
  20. 11 Jan, 2013 3 commits
  21. 10 Jan, 2013 1 commit
    • stop using a local cache on TaskDistributionTool · b2bffc14
      A dictionary was used as cached to store test result path and
      duration of tests. This was quite convenient, however this
      dictionary was growing, and since this data was commited thouzands
      time per day, this was making the zodb growing faster and faster.
      So we now rely on catalog + tags to retrieve test results. We
      also use int_index on test result line to order them by duration
      time. We will surely increase the load of sql database (we might
      need to add specific index), but this will avoid zodb using too
      much space.
      Sebastien Robin committed
  22. 06 Dec, 2012 1 commit
  23. 09 Nov, 2012 1 commit
  24. 08 Oct, 2012 1 commit
  25. 23 Apr, 2012 2 commits
  26. 16 Nov, 2011 1 commit