I have a Jenkins job, with SCM from bitbucket, two shell scripts, and a post build action publishing the result to Slack.
Naively I want to pass a concluded variable in the first shell script to the second, add some information to that variable in the second shell script, and then to append that variable to the Slack custom message.
I was expecting this to be a built in feature, and now spending few days on and off at it. I've tired the EnvInject, Environment Inject, Global Variable String Parameter plugins, but in any configuration I've tried it didn't work.
In some cases I got this error:
21:01:08 [EnvInject] - [ERROR] - The given properties file path 'build.properties' doesn't exist.
I know this file does not exist.. I expected the plugin to create it, so I can add new content to it in first shell script, and to be loaded in every other step of the job.
Am I missing something or misusing these plugins?
So like I've seen it happens too often, after asking the question, I was able to solve it like this:
First we create a shell script to create the file, I've already added a value:
Then we tell Jenkins to inject the variables from the build.properties file:
Then we change the value of the variable in the file:
Then AGAIN we tell Jenkins to inject the variables from the same file:
Then we can observe the value changes in the next shell:
Also in the post build action:
And success:
Related
I am new to Jenkins.
I have written a groovy script, which loads a token secret from an adjacent config.properties file.
What's the best way to execute this script in a groovy pipeline ?
What I think I need to do is:
download that script from SCM
change the token in config.properties (retrieved from the stored jenkins credentials)
execute that script
I've seen various options :
loading the script with load(), but this seems to be more dedicated to loading helper functions, whereas I only need to execute the whole script
using shared libraries, but this seems to be more dedicated to code snippets reused across multiple jobs, which is not my case
using withGroovy {}
using sh groovy
using a docker image that contains a groovy sdk
I tried these, and managed to get none of them to work (in part due to the extra-difficulty of retrieving the credential), so before I go any further I'd like to know what's the best option to proceed. For example, instead of trying to change the file config.properties in my pipeline to set the correct token, should I rather try to change my groovy script so that it takes the token from an environment variable ?
Thanks
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 want to put the name of the currently executing Jenkins job into an environment variable for use later in my pipeline, without the folder name. I'm assuming I need something like :
withEnv(['JOB_BASE_NAME=JOB_NAME.split('/').last()']) {
echo "Job base name: ${JOB_BASE_NAME}"
}
but I get an error:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException:
unclassified method java.lang.String div java.lang.String
In Jenkins documentation, you have the §Using environment variables section which mentions:
The full list of environment variables accessible from within Jenkins Pipeline is documented at localhost:8080/pipeline-syntax/globals#env, assuming a Jenkins master is running on localhost:8080
If you follow the link you can find that JOB_BASE_NAME is already provided OOTB by Jenkins so this is exactly what you want.
JOB_BASE_NAME -
Short Name of the project of this build stripping off folder paths, such as "foo" for "bar/foo".
I worked it out. In case anyone finds it useful:
def jobBaseName = "${env.JOB_NAME}".split('/').last()
echo "Job Name (excl. path): ${jobBaseName}"
might be too late, but thought would help someone in need for a simpler solution using bash.
${JOB_NAME%%/*}
Example:
I have a project created with name: poc_jenkins_pipeline
If i try accessing default jenkins variable ${JOB_NAME}
it returns value poc_jenkins_pipeline/develop i.e. <project name>/<branch name>
By using % operator in bash ${JOB_NAME%%/*} returns value poc_jenkins_pipeline
Reference Link - https://qa.nuxeo.org/jenkins/pipeline-syntax/globals
If you want the name of Jenkins job without the folder name you can use:
def job = "${JOB_BASE_NAME}"
Hoping someone can point me in the right direction.
I have just started to look at the Jenkins pipeline and am trying to work out how to trigger a parameterized build for a job that already exists using the Jenkinsfile
In my Jenkinsfile i have
node {
stage 'Build My Job'
build job: 'my-build'
}
I need to be able to pass a branch name from the Jenkinsfile config to the job that is running? If i am misunderstanding anything then please let me know
Thanks
Instead of starting with a Jenkinsfile, it's easier to start with a pipeline job in which you can directly edit the pipeline script. By clicking the 'Pipeline Syntax' link you can open the snippet generator, where you can generate the Groovy for a particular step:
This Snippet Generator will help you learn the Groovy code which can be used to define various steps. Pick a step you are interested in from the list, configure it, click Generate Groovy, and you will see a Groovy statement that would call the step with that configuration. You may copy and paste the whole statement into your script, or pick up just the options you care about. (Most parameters are optional and can be omitted in your script, leaving them at default values.)
In the configuration page select 'This project is parameterized' and sleect parameter type and enter parameter name
You can access this new parameter value in you jenkinsfile using 'env.parameterName'
In my Jenkins configuration I have a conditional step which exports a custom shell variable called "SUFFIX". I want to use this variable in name the of the project from which I am copying artifacts but it says:
Unable to find project for artifact copy: myProject${SUFFIX}_release
How can I use such a variable or achieve such a behaviour where the project name depends on a job parameter. The job parameter is a boolean value and should stay a boolean value. There should not be a string parameter SUFFIX.
Is this question related: Being clever when copying artifacts with Jenkins and multi-configurations
Do I need the EnvInject plugin to make variables accessible by the Copying artifacts plugin?
Jenkins does not retain environment variable changes between builds or build-steps. This is part of the design, to keep the build environment clean.
You cannot export an environment variable in Execute Shell build step, and then use it in Copy Artifacts build step. To get around this, you do need EnvInject plugin.
Instead of exporting your shell environment variable to the Environment, you need to write it to - properties file, in format param=value
Then, using EnvInject build step, load that properties file
After that, your newly loaded environment variable will be available to all subsequent build/post-build steps, including Copy Artifacts build step.