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 concurrent git pushes always safe if the second push only has fast-forwards from the first push?
  • Is “git ls-remote” a read-only operation?
  • When multiple clients push to same remote repository, how does git deal with concurrency issues?
  • Concurrency in a GIT repo on a network shared folder
  • git local concurrent access
  • How to put jobs in a category for the Throttle Concurrent Builds plugin for Jenkins
  •                 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?

    Thanks!

  • Do I need sonar and sonar runner for Jenkins?
  • Trouble building J2V8 on Ubuntu
  • How to prevent certain Jenkins jobs from running simultaneously?
  • how to get $CAUSE in workflow
  • I have an issue running a jenkins job in slave using maven (Maven home doesn´t exist)
  • Set up ruby globally for all users on ubuntu 14.04
  • 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:
    settings.

    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 (https://wiki.jenkins-ci.org/display/JENKINS/Build+Flow+Plugin) potentially together with Job DSL plugin (https://wiki.jenkins-ci.org/display/JENKINS/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.