The Setup - A jenkins job using jenkins parameters testApp and testEnv. The Execution Batch looks like this:
C:\jmeter\apache-jmeter-3.2\bin\jmeter.bat -n -t
C:\JMeter\Scripts\API_scripts\%testApp%.jmx -Jtestenv=%testEnv% -JtestApp=%testApp% -JtestBrowser=NA -l
C:\AUTO_Results\jtl\%testApp%_%testEnv%.jtl
Post-build Actions
Console output (build lob) parsing with a global rule so that the Failures that are logged in the Jenkins Console window will consider the JMeter script failing. (discussed Jenkins shows JMeter script failure even though the script actually passed)
Triggered parameterized build - this is a separate jmeter script that updates a wiki page with either PASS/FAIL and uploads the JMeter report.
The Issue - How do I get the downstream Triggered build to use the parameters from the upstream script? I set the Parameter = Current build parameters but it's not applying those. Also, I wont know the value of the testResult parameter until the upstream build finishes. I tried adding %testResult%=PASS to the 'Predefined parameters' box
As per Parameterized Trigger Plugin page:
The parameters section can contain a combination of one or more of the following:
a set of predefined properties
properties from a properties file read from the workspace of the triggering build
the parameters of the current build
Subversion revision: makes sure the triggered projects are built with the same revision(s) of the triggering build. You still have to make sure those projects are actually configured to checkout the right Subversion URLs.
Restrict matrix execution to a subset: allows you to specify the same combination filter expression as you use in the matrix project configuration and further restricts the subset of the downstream matrix builds to be run.
So you basically need to copy over the parameters you would like to have in the "downstream" job from the current one.
As a workaround to current performance plugin limitations you can consider running JMeter using Taurus tool as a wrapper, it has flexible and powerful pass/fail criteria subsystem which will basically return to Jenkins non-zero exit code triggering build failure in case of issue in the test. If everything goes well Taurus exit code will be 0 which is considered successful by Jenkins. Check out How to Run Taurus with the Jenkins Performance Plugin article for more details.
Related
I set up a Jenkins to integrate the JMeter script. Using the Freestyle project in Jenkins, I enabled "This project is parameterized" to set a String parameters for the Threads, Loop_Count and Think Time.
In .jmx file, I used the Function Parameters function to define those
variables, as shown below image:
User Defined Variable
In Jenkins, I configured the parameterization as shown below:
Set Parameterization
Command Line
However, when running the test for 40 users using the Build parameter in Jenkins, it looks like the # of threads/users are not correct that is being executed, the Samples that are being generated only 3 for most of the pages. Only the Homepage (which is the first page on the test) is only getting the correct # of Samples, but the rest of the URLS/pages are not correct. Below the actual output.
Output
Can you please help what might the causing this issue, I already checked the Jmeter script and jenkins config and appears to be correct but still I'm getting the issue. Thanks for the help.
Setting parameters in Jenkins itself is not sufficient to pass them to JMeter, you need to pass this parameterized value to JMeter startup script via -J command-line argument
-Jusers=%users%
End-to-end demo:
More information: Apache JMeter Properties Customization Guide
I have 2 jobs 'job1' and 'job2'. I will be triggering 'job2' from 'job1'. I need to get the console output of the 'job1' build which triggered 'job2' and want to process it in 'job2'.
The difficult part is to find out the build number of the upstream job (job1) that triggered the downstream job (job2). Once you have it, you can access the console log, e.g. via ${BUILD_URL}consoleOutput, as pointed out by ivoruJavaBoy.
How can a downstream build determine by what job and build number it has been triggered? This is surprisingly difficult in Jenkins:
Solution A ("explicit" approach): use the Parameterized Trigger Plugin to "manually" pass a build number parameter from job1 to job2. Apart from the administrational overhead, there is one bigger drawback with that approach: job1 and job2 will no longer run asynchronously; there will be exactly one run of job2 for each run of job1. If job2 is slower than job1, then you need to plan your resources to avoid builds of job2 piling up in the queue.
So, some solution "B" will be better, where you extract the implicit upstream information from Jenkins' internal data. You can use Groovy for that; a simpler approch may be to use the Job Exporter Plugin in job2. That plugin will create a "properties" (text) file in the workspace of a job2 build. That file contains two entries that contain exactly the information that you're looking for:
build.upstream.number Number of upstream job that triggered this job. Only filled if the build was triggered by an upstream project.
build.upstream.project Upstream project that triggered this job.
Read that file, then use the information to read the console log via the URL above.
You can use the Post Build Task plugin, then you can get the console output with a wget command:
wget -O console-output.log ${BUILD_URL}consoleOutput
I am attempting to write a custom pre-send script for Jenkins email-ext plugin. I'm at the point where I can write a simple 'hello world' groovy script and run it with the "Email template testing" tool for the job I want to customize.
Alas, I'm having a bit of trouble navigating Jenkins build API. As a starting point, the job whose email I want to customize has N build steps. I only want to send an email if one of those steps faild, and I'd like to write a different message depending on which step failes.
How can determine the number of steps in the build (N), and which step failed?
Which build step caused the build result to change is only recorded in the console output, e.g.
Build step 'Execute shell' marked build as failure
This isn't otherwise stored as part of the build record, and so isn't available via the API.
So you would have to try scraping the console output to do what you want.
To determine how many build steps there are, you'd need to fetch the job configuration via /job/foo/config.xml and count how many items there are within the <project><builders> tag (assuming a freestyle project).
I have a jenkins job that runs some tests and promotes the build if all tests pass.
I then have a second job that has a 'Promoted build parameter' which is used for deployments.
THe idea is that the deply job should let you pick one of the prompted builds for deploying. The issue I'm having is that I can pick a promoted build, but I have not idea how I access information about the build.
I've named the build parameter
SELECTED_BUILD
And according to the docs this should then be available via the environment.
The problem is that it doesn't seem to be bound to anything.
If I run a build step to exectute this sheel script:
echo $SELECTED_BUILD
echo ${SELECTED_BUILD}
The values are not interpolated / set.
Any idea how I can access the values of this param?
Many Thanks,
Vackar
Inject the information as variable user jenkins plugin (eject evn variable).
while triggering parameterized build on other job, pass above variable as parameter to next job.
I'm using the Scriptler plugin for Jenkins, and am having a hard time finding any information on how to share the scriptler scripts I'm writing between scripts. I've tried using the ScriptHelper from the Scriptler API, but have run into issues when passing in arguments to the script.
Anyone else come across this and solve it? Is there a standard way to do this (without calling the Jenkins REST API) to execute a script?
More Details
We have a full build MultiJob that contains many phase jobs, each with their own artifacts, with a 3 day time to live on them. When a this full build job is promoted, a scriptler runs against it, pulling each of the phase jobs artifacts into the full build job. By doing so, we can keep the full build alive forever, without changing the lifetime on the artifacts for each phase job (essentially 'keep this build forever' on the full build, ignoring the lifetimes set in the phase jobs.
We also want to pull these artifacts into a deploy job. The idea is that we can point a deploy job to a full build, and it will pull out the artifacts we specify. If the full build is promoted, this script will pull the artifacts directly from the full build job, otherwise, it will pull them from the internal phase jobs. Since we have 2 scripts that work with MultiJobs, I would like to be able to share this code between them.
The script would take a MultiJob name and build number, and return the individual phase job's build numbers, build statuses, and artifact information.
This is possible using Groovy capabilities, though I don't know if Scripler supports it directly. If you are running on the master node, you can use Groovy evaluate. Scriptler scripts are stored as Groovy files on the file system of the master node in the $JENKINS_HOME/scriptler/scripts directory. The Scripter ID is the function name within that directory.
Here is a very simple example. It uses two files. The first is the parameterized function, findByScm.groovy, which finds jobs using a give source control type. The second script, findByGitScm.groovy will evaluate the first function for Git SCMs and print the results.
findByScm.groovy
import jenkins.model.*
jenkins = Jenkins.instance;
// Notice that myScmType is not defined in this function
scmJobs = jenkins.items
.findAll { job -> job.scm != null && job.scm.type == myScmType }
findByGitScm.groovy
// This is supplying the argument to findByScm.groovy
myScmType = 'hudson.plugins.git.GitSCM'
// Now we are evaluating the script
evaluate(new File("${System.getProperty('JENKINS_HOME')}/scriptler/scripts/findByScm.groovy"))
// scmJobs is a variable which was introduced in findByScm.groovy
scmJobs.each { println it }