splitTests: Split Test Runs

• parallelism
  Nested Choice of Objects
  • count
    Always divide the tests into N parallel sub-tasks of about equal size. This mode is useful if your build slaves are not elastic to control the resource consumption by this task.

    • size : int
  • time
    Divide the tests into parallel sub-tasks each no bigger than N minutes. Combined with elastic slaves, such as EC2, the turn-around time of the tests will remain the same no matter how many tests you add.

    This value counts just the time spent on executing tests, and not including other time such as checking out the code, building the test, etc. For example, if your test job spends 50 minutes in tests and 60 minutes total from start to finish, then you have 10 minutes "fixed" overhead regardless of the number of tests it executes. If you use this mode and set the value to "10 minutes", then you'll have 5 parallel sub-tasks that all ends in roughly 20 minutes (20 mins = 10 mins tests time + 10 mins overhead.)

    "N minutes per a sub-task" is a goal, not a hard constraint. So a sub-task can take longer (for example if you have a single test that takes more than N minutes.)

    • mins : int
• estimateTestsFromFiles : boolean (optional)
  The first run (or a run without any reference to test result from previous runs) will estimate tests according the content of workspace and maven java project patterns for tests. The Tests will be splitted according to this estimation.
• generateInclusions : boolean (optional)

  If disabled, the splitStep call will return a List<List<String>> containing the exclusion patterns for the different buckets.

  If enabled, the splitStep call won't return a List<List<String>>.
  Instead it will return a List of a structure with :

  • boolean includes whether the following list is an inclusion or an exclusion list
  • List<String> list the list of patterns

• stage : String (optional)
  If defined, only consider tests recorded in the previous build in the named stage.