LR Bamboo

LoadRunner CD with Atlassian Bamboo.

Jenkins is great and we now have a fully working commercial CI solution for LoadRunner - see my other pages on this site.

[Bamboo UPDATE: See my other bash and Jenkins pages on this site for up-to-date techniques: LR Bash2, Jenkins V2 and Bash Methods. We are tending now towards using Jenkins V2 for our LoadRunnrer work but the dev teams are using Bamboo now for all there deployments etc. so we do need to combine these methods.]

But of course, once youíve got it all working in the IT industry it has to change! We need to switch to Bamboo, a commercial upgrade to Jenkins, aimed at continuous delivery rather than just integration, with far more options for the developers. We need to make the move.

So, Iíve cobbled together a working solution for Bamboo (HP do suggest some 3rd party plugins that work with ALM, if you have that)

I havenít used this yet. This is a startup project.

Bamboo has an ssh capability built in:
https://confluence.atlassian.com/display/BAMBOOCLOUD/Using+the+SSH+task+in+Bamboo

And we need to get the final analysis XML results from a LoadRunner scenario run into Bamboo so we can decide on pass/fail based on SLA status.

You can run LoadRunner from the command line and you can run the analysis with specific templates, so you can get reports and automatically shutdown, again, all from the command line. However, it doesnít seem straight forward to get the XML results file that the Jenkins plugin produces.

So for now at least, I am going to run the Jenkins CI jobs using curl and ssh and copy over the final XML file to Bamboo and use that for setting the Bamboo status.

Jenkins local on the controllers

One thing to watch (if you have setup your controllers as suggested on this site) is the location of the Jenkins local build location on your AWS boxes. You want this to be on the larger temporary Z drive. And of course, if you shut down your instances, you will lose this store.

I did find the most reliable way to do this is change the JENKINS_HOME value in the jenkins.xml file. And then copy over the whole jenkins installation to the z drive. Remember this will be lost on shutdown and youíll need to repeat this process when you startup a new controller - Iíll work on this later, when I have to use this solution in earnest.

inside the jenkins.xml file now:

    <service>
      <id>jenkins</id>
      <name>Jenkins</name>
      <description>This service runs Jenkins continuous integration system.</description>
      <env name="JENKINS_HOME" value="z:\jenkins_local"/>

Restart the Jenkins service after this change.

Running the Jenkins LoadRunner jobs from Bamboo

So far I have just experimented with this from a cygwin shell. Iím publishing this now for my notes moving forwards.

The LR controller setup on this site has Jenkins running on port 80 and this port is open on the firewalls (Iíve restricted it to my office). This is really useful Ďcos you can easily:

1. run a job with curl (just grab the url from the Jenkins web front end):

2. Use ssh and a bash loop to wait until the job has finished - I check for a new set of jtl files:

    sleep 60
    jtl_expected="5"
    count_jtl="0"
    status_check_count="0"
    status_check_limit="20"

    while [ "$count_jtl" -lt "$jtl_expected" ]&& [ $status_check_count -lt $status_check_limit ]
    do
       echo $status_check_count $count_jtl
       sleep 60
       status_check_count=$(( $status_check_count + 1))
       count_jtl=$(/cygdrive/c/cygwin64/bin/ssh.exe -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -i /cygdrive/c/backup/Graylog_openSSH_restricted.ppk jenkins@54.xx.xx.xxx ls /cygdrive/z/jenkins_local/jobs/all4_check_urls_15mins/workspace/*.jtl | wc -l)
    done
    echo $status_check_count $count_jtl

3. Once the Jenkins job has finished, tar up the workspace, bring over to the local box and untar it:

    #tar up the workspace
    /cygdrive/c/cygwin64/bin/ssh.exe -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -i /cygdrive/c/backup/Graylog_openSSH_restricted.ppk jenkins@54.xx.xx.xxx tar -czvf '/cygdrive/c/Program\ Files\ \(x86\)/Jenkins/jobs/all4_check_urls_15mins/workspace.tar.gz' '/cygdrive/c/Program\ Files\ \(x86\)/Jenkins/jobs/all4_check_urls_15mins/workspace'
    #copy over the workspace
    /cygdrive/c/cygwin64/bin/scp.exe -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -i /cygdrive/c/backup/Graylog_openSSH_restricted.ppk -rp jenkins@54.xx.xx.xxx:'/cygdrive/c/Program\ Files\ \(x86\)/Jenkins/jobs/all4_check_urls_15mins/workspace.tar.gz' .
    #untar the workspace locally
    tar -zxvf workspace.tar.gz -C .

4. Havenít done this bit yet but I plan to run a bash script on the XML results file that is in the workspace folder. This script will be similar to Ďsla_to_jtl.shí found elsewhere on this site. It will parse the XML results and come up with a pass/fail in a format that Bamboo can use

It does look like Bamboo will honour bash return values for setting pass/fail criteria so that should be fine. Found this snippet on the internet in a Bamboo script, using return values for pass/fail:

    #!/bin/sh
    set -o errexit

    ARTIFACT_VERSION=$1
    if [ ! -z "$ARTIFACT_VERSION" -a "$ARTIFACT_VERSION" != " " ]; then
       echo "Provided artifact version: $ARTIFACT_VERSION"
       exit 0
    else
       echo "Artifact version is missing" 1>&2
       echo "Run a customized Build and override the build variable 'webforms.blueprint.version'." 1>&2
       exit 1
    fi
    exit 0

 

[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 BASH] [LR BASH2] [LR Methods] [LR CI BASH] [Bash methods] [Jenkins V2] [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