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:
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:
<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:
while [ "$count_jtl" -lt "$jtl_expected" ]&& [ $status_check_count -lt $status_check_limit ]
echo $status_check_count $count_jtl
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 firstname.lastname@example.org ls /cygdrive/z/jenkins_local/jobs/all4_check_urls_15mins/workspace/*.jtl | wc -l)
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 email@example.com 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 firstname.lastname@example.org:'/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:
set -o errexit
if [ ! -z "$ARTIFACT_VERSION" -a "$ARTIFACT_VERSION" != " " ]; then
echo "Provided artifact version: $ARTIFACT_VERSION"
echo "Artifact version is missing" 1>&2
echo "Run a customized Build and override the build variable 'webforms.blueprint.version'." 1>&2