J V2 Pipeline1

Jenkins V2 - A Simple Pipeline Approach

The ‘excuse’ for this page is that I am new to Jenkins V2 and pipelines in general. And in fact I am a tester these days rather than a developer. (So it will be worth talking to one of your developers about all of this). Having said that, this is working for me with LoadRunner CI and complex build projects.

Contents:

    1. Running Jenkins V1 jobs in sequence

    2. TEST 2 - check above that a follow up build resets the pass/fail

    3. Jenkins V2 Pipeline groovy script for full deployment and CI Perf test

Running Jenkins V1 jobs in sequence

Basically, I want to build complex service layers (deployed from separate systems, such as: Bamboo). I do have older Jenkins v1 jobs for deployments and various performance testing scenarios. But now I want a robust process for building these and then running several CI performance tests in sequence, say over a weekend.

This is where Jenkins V2 and PIPELINES come in to it:

Lets say I want to build two services, dependent on each other, using the latest dev builds if possible, but otherwise definitely building something for the weekend CI runs:

Example results:

ScreenShot049

Now, in fact the above output is just from a test script, where I suppose the first dependency fails from it’s development branch and I have to force the master branch in place of that, so the weekend CI job can continue as best it can:

Jenkins V2 Pipeline groovy script for the above


    try {
               // run tests in the same workspace that the project was built
               echo 'inside b1a first try area'
               b1a = build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
           } catch (e) {
               // if any exception occurs, mark the build as failed
               echo 'inside b1a catch area --> b1a build must have FAILED'
              
               build job: 'ccs from master - set to pass here', propagate: true
               //currentBuild.result = 'FAILURE'
               //throw e
              
               echo 'FORCING overall current build status to SUCCESS'
               currentBuild.result = 'SUCCESS'
           } finally {
               // perform workspace cleanup only if the build have passed
               // if the build has failed, the workspace will be kept
               //step([$class: 'WsCleanup', cleanWhenFailure: false])
               echo 'inside b1a -finally- step - nothing to do here yet.'
           }

This is all designed off site for my own test purposes, however I will be instigating this at work, with several more complex steps and decisions. This page (and script) are really just to test the initial idea and check the code.

Jenkins V2 has the big advantage for me with it’s plugins and known good support for LoadRunner CI (see elsewhere on this site). Hopefully over the coming months we can make further progress with this approach, watch this site for updates.

TEST 2 - check above that a follow up build resets the pass/fail

I just want to be sure that once I’ve hard coded the pass/fail above, that a follow up job, say a performance test, will properly reset the pipeline status:

ScreenShot050

I’ve added a few extra lines to the above pipeline script, using a node element to run a new job:

Jenkins V2 Pipeline groovy script for the above


    try {
               // run tests in the same workspace that the project was built
               echo 'inside b1a first try area'
               b1a = build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
           } catch (e) {
               // if any exception occurs, mark the build as failed
               echo 'inside b1a catch area --> b1a build must have FAILED'
              
               build job: 'ccs from master - set to pass here', propagate: true
               //currentBuild.result = 'FAILURE'
               //throw e
              
               echo 'FORCING overall current build status to SUCCESS'
               currentBuild.result = 'SUCCESS'
           } finally {
               // perform workspace cleanup only if the build have passed
               // if the build has failed, the workspace will be kept
               //step([$class: 'WsCleanup', cleanWhenFailure: false])
               echo 'inside b1a -finally- step - nothing to do here yet.'
           }

    node('master') {
       // some block
       //bat 'c:\\cygwin64\\bin\\bash -c df'
      
       b1b = build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
    }

So we can be sure that even after resetting the pipeline status (after making a decision change), follow up jobs will still behave as expected. This does allow us some scope in CI test design.

Jenkins V2 Pipeline groovy script for full deployment and CI Perf test

This test script is just to document a possible full approach to checking all the deployments needed and running a CI Perf test at the end, with exit points where needed. I have run some basic tests with this approach at home and will talk to the team before moving forwards with my proper solution at work. Below I have simply re-used my makeshift Jenkins v1 jobs but of course the jobs can be changed as required:

ScreenShot053

Jenkins V2 pipeline Groovy script for the above test run

try
{
   build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
}
catch (e1)
{
   echo 'inside first catch area --> dev build must have FAILED. Try step 2:'
  
   echo 'FORCING overall current build status to SUCCESS here'
   currentBuild.result = 'SUCCESS'
      
   try
   {
       build job: 'ccs from master - set to pass here', propagate: true
   }
   catch (e2)
   {
       echo 'inside second catch area --> master build must have FAILED. Need to exit pipeline now.'
       currentBuild.result = 'FAILURE'
       return
   }
}

try
{
   build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
}
catch (e3)
{
   echo 'inside first catch area --> dev build must have FAILED. Try step 2:'
  
   echo 'FORCING overall current build status to SUCCESS here'
   currentBuild.result = 'SUCCESS'
      
   try
   {
       build job: 'ccs from master - set to pass here', propagate: true
   }
   catch (e4)
   {
       echo 'inside second catch area --> master build must have FAILED. Need to exit pipeline now.'
       currentBuild.result = 'FAILURE'
       return
   }
}
try
{
   build job: 'ccs from develop - set to fail here', propagate: true, quietPeriod: 20
}
catch (e5)
{
   echo 'inside first catch area --> dev build must have FAILED. Try step 2:'
  
   echo 'FORCING overall current build status to SUCCESS here'
   currentBuild.result = 'SUCCESS'
      
   try
   {
       build job: 'ccs from master - set to pass here', propagate: true
   }
   catch (e6)
   {
       echo 'inside second catch area --> master build must have FAILED. Need to exit pipeline now.'
       currentBuild.result = 'FAILURE'
       return
   }
}
 

Last check on the above

I just changed one of the called jobs to force a fail at a master point, to make sure behavior is as expected. All went according to plan:
 

ScreenShot054

NOTE: above that I am generally not throwing the errors. If we do, then this will stop the pipeline dead, unless we set ‘propogate: false’ as per below:

    build job: 'ccs from develop - set to fail here', propagate: false, quietPeriod: 20

BUT if that is set, then the errors are ignored and we don’t get into the catch area, in order to run our alternatives.

So the above approach, with ‘propogate: true’ set AND ‘throw e’ NOT in use, gives just the workflow that we need for our full pipeline control UNLESS:

    You have a point where you do need to stop the pipeline abruptly. THEN, you can throw the error, to achieve that end.

 

[Home] [About (CV)] [Contact Us] [JMeter Cloud] [webPageTest] [_64 images] [asset moniitor] [Linux Monitor] [Splunk ETL] [Splunk API] [AWS bash] [LR Rules OK] [LR Slave] [LR CI Graphs] [LoadRunner CI] [LR CI Variables] [LR Bamboo] [LR Methods] [LR CI BASH] [Bash methods] [Jenkins V2] [J V2 Pipeline1] [Jv2 Jobs] [Jv2 Analysis] [Jv2 Analysis2] [Streaming vid] [How fast] [Finding Issues] [Reporting] [Hand over] [VB Scripts] [JMeter tips] [JMeter RAW] [Dynatrace] [Documents] [FAQ] [Legal]

In the Cartesian Elements Ltd group of companies