How start identical jobs with different parameters in parallel execution?

I have a build job and a test job parameters.

I want to be after the build job, simultaneously run test job with one parameter and the same test job with different parameters in parallel execution.

  • Are rugged Repository instances threadsafe?
  • Locking strategy of git to achieve concurrency?
  • Concurrent git clone and fetch
  • When multiple clients push to same remote repository, how does git deal with concurrency issues?
  • Parallel/Concurrent/Multi-threaded transfers to and from git server?
  • git local concurrent access
  •                 build job  
                      / \  
             test job    test job
       with one params    with other params
                |             |

    How to accomplish this and whether it is possible to perform without having to write your own plugin?


  • Jenkins Git Publisher tag not detecting environment variables
  • Git post-receive hook not working
  • Problems launching the slave agent via Java Web Start on Jenkins
  • Xamarin - Cross Platform Unit Testing
  • Jenkins automatically commit artifacts
  • tutorial about configuring jenkins to run tests before git pushing commits
  • 7 Solutions collect form web for “How start identical jobs with different parameters in parallel execution?”

    When you create your test job, create it as a “Build multi-configuration project”
    While configuring the job select “Configuration Matrix” then “User-defined axis”

    You can use the name of this axis as a parameter in your job. the given parameters will be started simultaneous in different jobs. (if enough executors are available)

    Playing off @Soo Wei Tan’s answer, I found the following works well.

    • Parameterized Trigger Plugin
    • Choose “Parameter Factory”
    • Choose “For every property file, invoke one build”

    Then, in a shell, write a series of property files, and the Trigger Plugin will take care of the rest.

    You can even combine this with a matrix style job at the top level in interesting ways. For example, triggering on the user-defined axis, keeping track of it all with a grid. Really quite a flexible approach, if a bit hidden.

    Assuming you know the parameters when you are finishing your build job, you can use the Parameterized Trigger Build plugin to fire both downstream jobs with different parameters.

    I had the same requirement, and found that Parameterized Trigger Plugin was not flexible enough for passing different parameters to different (or the same) jobs in parallel. Yes you can use a Parameter Factory with property files, but that would mean adding new property files to my version control solely for the purpose of configuring Jenkins. A Multi-Configuration project with a configuration matrix also seemed overcomplicated.

    The better and more straightforward solution for me was the Multijob Plugin, which has the concept of Phases. A MultiJob can have multiple phases. Phases run sequentially and jobs within a phase will run concurrently (in parallel).

    After installing the MultiJob plugin, when creating a new Jenkins item, select MultiJob Project. You can then create one or more phases.
    Each job within a phase has it own parameters, click Advanced… -> Add Parameters

    Also it is very easy to configure what should happen if a particular job fails, should the entire MultiJob continue or fail etc, see the Kill the phase on: and Continuation condition to next phase
    when jobs’ statuses are:

    For me this was much more intuitive to use than the Parameterized Trigger Plugin or a Mult-Configuration project, and did not require any extra configuration outside of Jenkins.

    One option would be to use Build Flow plugin ( potentially together with Job DSL plugin ( You can use Job DSL to define job steps that invoke your build with different command line arguments and orchestrate the build with Build Flow.

    I have a slightly different use case. We have test jobs that run against our main build during the development cycle. Toward the end of the cycle; we create a release candidate build and run the same tests against that. We want to also continue testing the main build.

                   Main Build     Release Build
                             \   /
                           same set of tests

    I can create duplicate jobs with just different names to handle this. But there have to be a more elegant/simpler way.

    Could you please say a bit more why do you need your test jobs to run concurrently?

    I do use test that need to split and run simultaneously, but I use a single Jenkins/Hudson job that has a weight > 1 (see Heavy Job Plugin).

    Git Baby is a git and github fan, let's start git clone.