3

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?

tftd
  • 371
  • 1
  • 7
  • 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 Oct 22 '19 at 15:26
  • 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 – jayhendren Oct 22 '19 at 15:27
  • 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 Oct 22 '19 at 20:19
  • 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. – jayhendren Oct 23 '19 at 15:42

0 Answers0