Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2019-10-22T15:26:46.050Z
Comments: 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
Comments: jayhendren
Comments: CC BY-SA 4.0
Comments: 2019-10-22T15:27:56.687Z
Comments: You may also be interested in: https://stackoverflow.com/questions/36422888/how-do-i-implement-a-retry-option-for-failed-stages-in-jenkins-pipelines
Comments: jayhendren
Comments: CC BY-SA 4.0
Comments: 2019-10-22T20:19:33.673Z
Comments: 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. :)
Comments: tftd
Comments: CC BY-SA 4.0
Comments: 2019-10-23T15:42:19.130Z
Comments: 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.
Comments: jayhendren
Tags: <jenkins><jenkins-pipeline>
Title: Is it possible to queue multiple replays of a Jenkins pipeline programmatically?
UserDisplayName: tftd
ThreadText: # 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
  
  