The following plugin provides functionality available through Pipeline-compatible steps. Read more about how to integrate steps into your Pipeline in the Steps section of the Pipeline Syntax page.

For a list of other such plugins, see the Pipeline Steps Reference page.

Parallel Test Executor Plugin

splitTests: Split Test Runs

Asks Jenkins to analyze the timing of tests from the last build and divide the tests for this build into roughly equal subsets for parallel execution. example Jenkinsfile
  • 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)
  • 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.
  • testMode (optional)

    Configure how exclusions and inclusions are formed from the JUnit result XML. The test job receiving the exclusion/inclusion files must be able to handle the format produced by the selected mode.

      Nested Choice of Objects
    • javaClass
      This mode works best with java projects.

      Each exclusion/inclusion generates two lines by replacing "." with "/" in the fully qualified test class name and appending ".java" to one line and ".class" to the second line.

      • javaTestCase
        This mode works best with Java projects.

        Parallelize per Java test case.

        It is also able to estimate tests (per class) to run from the workspace content if no historical context could be found.

        • testCase
          Each exclusion/inclusion generates one line consisting of the test case name only.

          This is useful where a tool produces JUnit result XML containing unique test case names without any class prefix.

          • qualifiedTestCase
            If checked, each exclusion/inclusion generates one line consisting of the class and test case name on a className.testName format.

          Was this page helpful?

          Please submit your feedback about this page through this quick form.

          Alternatively, if you don't wish to complete the quick form, you can simply indicate if you found this page helpful?


          See existing feedback here.