<p>We have a parameterized declarative Jenkins pipeline which does tests on a java project with maven. The pipeline goes through a lot of stages to ensure that the code works as expected. However, every now and then we hit some concurrency/parallelization issues in our project's tests. Normally the way we "catch" these issues is by manually doing a N <code>replays</code> of a specific triggered PR/branch build. </p>

<p>What I'm trying to achieve is to automate this through the pipeline so that one can select a <code>choice</code> parameter before triggering the build and it would automatically queue the amount of builds.</p>

<p>I was thinking of doing something like this:</p>

<pre><code>pipeline {
    parameters { 
        choice(defaultValue: 'false', choices: ['false', '5', '10', '15', '20'], description: 'If this field is set, it will queue additional builds (useful in parallel testing)', name: 'ADDITIONAL_BUILDS')
    }
}
</code></pre>

<p>And before the <code>pipeline</code> is executed to have a loop which does:</p>

<pre><code>if(!ADDITIONAL_BUILDS.equals('false')) {
    for (int i = 0; i &lt; ADDITIONAL_BUILDS; i++)
    {
        build job: env.JOB_NAME, wait: false, parameters: parameters
    }
}
</code></pre>

<p>However, the issue with this is that it'll not use the correct revision (i.e. if the code is updated in-between, the next build will use the latest revision). Is there any way the <code>build</code> step can be used with a specific revision (other than passing yet another parameter)? Or maybe there is a way to programmatically do what <code>replay pipeline</code> does?</p>

CC BY-SA 4.0
2019-10-22T15:26:46.050Z
I suggest you use the built-in retry step instead of a loop: https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#retry-retry-the-body-up-to-n-times
jayhendren
CC BY-SA 4.0
2019-10-22T15:27:56.687Z
You may also be interested in: https://stackoverflow.com/questions/36422888/how-do-i-implement-a-retry-option-for-failed-stages-in-jenkins-pipelines
jayhendren
CC BY-SA 4.0
2019-10-22T20:19:33.673Z
Thanks for your suggestion @jayhendren! However the `retry` step is not what we're after as it will retry the build only if it fails. We literally need to queue exactly N builds to be sure some parallel tests are working properly. :)
tftd
CC BY-SA 4.0
2019-10-23T15:42:19.130Z
I understand, which is why I didn't post that as an answer.  I just thought you would find `retry` to be an improvement over the for loop, since `retry` will exit the loop once the steps inside the block succeed, instead of a for loop where the steps inside the block will be run until you reach the maximum number of iterations, regardless of success or failure.
jayhendren
<jenkins><jenkins-pipeline>
Is it possible to queue multiple replays of a Jenkins pipeline programmatically?
tftd
# Is it possible to queue multiple replays of a Jenkins pipeline programmatically?

(Asked by: username_0 on 2019-10-21)

We have a parameterized declarative Jenkins pipeline which does tests on a java project with maven. The pipeline goes through a lot of stages to ensure that the code works as expected. However, every now and then we hit some concurrency/parallelization issues in our project's tests. Normally the way we "catch" these issues is by manually doing a N replays of a specific triggered PR/branch build. 
What I'm trying to achieve is to automate this through the pipeline so that one can select a choice parameter before triggering the build and it would automatically queue the amount of builds.
I was thinking of doing something like this:
pipeline {
    parameters { 
        choice(defaultValue: 'false', choices: ['false', '5', '10', '15', '20'], description: 'If this field is set, it will queue additional builds (useful in parallel testing)', name: 'ADDITIONAL_BUILDS')
    }
}

And before the pipeline is executed to have a loop which does:
if(!ADDITIONAL_BUILDS.equals('false')) {
    for (int i = 0; i < ADDITIONAL_BUILDS; i++)
    {
        build job: env.JOB_NAME, wait: false, parameters: parameters
    }
}

However, the issue with this is that it'll not use the correct revision (i.e. if the code is updated in-between, the next build will use the latest revision). Is there any way the build step can be used with a specific revision (other than passing yet another parameter)? Or maybe there is a way to programmatically do what replay pipeline does?

**Tags:** jenkins, jenkins-pipeline

> **Comments:**
> **username_1**: I suggest you use the built-in retry step instead of a loop: https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#retry-retry-the-body-up-to-n-times  
> **username_1**: You may also be interested in: https://stackoverflow.com/questions/36422888/how-do-i-implement-a-retry-option-for-failed-stages-in-jenkins-pipelines  
> **username_0**: Thanks for your suggestion @username_1! However the `retry` step is not what we're after as it will retry the build only if it fails. We literally need to queue exactly N builds to be sure some parallel tests are working properly. :)  
> **username_1**: I understand, which is why I didn't post that as an answer.  I just thought you would find `retry` to be an improvement over the for loop, since `retry` will exit the loop once the steps inside the block succeed, instead of a for loop where the steps inside the block will be run until you reach the maximum number of iterations, regardless of success or failure.  

---

## 0 answers

