In my Jenkins system configuration page, I have 3 variables defined, namely, sandbox_deployed, staging_deployed, and production_deployed. In my pipeline, I want to access one of these variables, based on a pipeline property, BUILD_ENV, defined in the job's configuration page. In other words, in my job's configuration page I have
BUILD_ENV=sandbox
How can I write pipeline code that does
println "$env.${env.BUILD_ENV}_deployed"
If I write it like in the above println, I get
org.jenkinsci.plugins.workflow.cps.EnvActionImpl#336841dd.sandbox_deployed
But I really want this
println "env.sandbox_deployed"
which prints out the correct value of the sandbox_deployed variable.
Try this code, at least it worked for me
println "${env."${env.BUILD_ENV}_deployed"}"
Related
There is declarative pipeline. In the beginning of pipeline block the agent selection is made using agent directive. Label-based selection is being conducted. Agent selected this way is the standard/default agent.
How to set for whole pipeline a special agent when certain condition is met?
The plan is to do condition check based on pipeline's one parameter >> can that work?
What are the points the chosen approach needs to address?
Current solution blueprint:
Groovy code prior to pipeline block
Mentioned groovy code sets a variable based on value of pipeline's parameter how to access pipeline's parameter from within Groovy code located out of pipeline?
agent section uses variable set in Groovy code matching label special agent got attached to
Both Jenkins.io and Cloudbees do not support dynamic agent selection with Declarative Pipeline syntax. Hence adding "when" expression within agent block will not work. However, the below approach can be tried
1. Create pipeline library - with a groovy file in vars folder. Keep all the stages inside this file and parameterize the "Agent" block
2. Jenkinsfile - embed the library inside Jenkinsfile and invoke the above groovy file using call(body) syntax. Pass agent deciding parameter from this Jenkinsfile.
For library syntax, please refer this url
Shared Library syntax
I have a parameterized project. With the variable VAR1.
I'm using the the Xray for JIRA Jenkins Plugin for Jenkins. There you can fill four parameters:
JIRA Instance
Issues
Filter
File Path
I'm new to Jenkins but what I have learned so far, that you can't fill this fields with environment variables. Something like
Issues: ${VAR1} - doesn't work.
So I thought I can do this with a pipeline. When I click on Pipeline Syntax and chose step: General Build Step I can choose Xray: Cucumber Features Export Task. Then I fill the fields with my environment variable and click Generate Pipeline Script The output is as follows:
step <object of type com.xpandit.plugins.xrayjenkins.task.XrayExportBuilder>
That doesn't work. What I'm doing wrong?
All you're doing is OK, but what you want is not supported by Jenkins whether it is pipeline or not, since the parameters' load is happening prior to the pipeline-flow or the definition of the ${VAR1}.
You can try to overcome this by defining the 'Issues' value as a pipeline internal value instead of a parameter and base it on the ${VAR1} value.
If it must be a parameter, use 2 jobs where one defines the value of 'Issues' based on a the ${VAR1} and pass it to the other job that gets the 'Issues' as a fixed value.
In a Jenkins job, I have a groovy script, that is split in two parts. It does something before SCM and does some other thing at the end of the job as last build instruction.
Now, I need to access a variable in the second part, that I set in the first part.
How to do that?
I tried to mark a variable as a field with #Field Boolean myFlag = false, but still myFlag cannot be accessed in the second part of the script.
Interpreter says:
groovy.lang.MissingPropertyException: No such property: myFlag for class: Script1
Does anyone know how to accomplish accessing a variable from the first part of the script in the second?
Thanks!
you can pass these variables as the Jenkins Job's parameters. That way you have access to the variables throughout.
It was not clear from your question if you're running a single script in the job or if you're executing multiple scripts.
I want to get the name of the Jenkins job. The name is a Jenkins environmental variable called JOB_NAME (and which looks like project_name/branch). JOB_BASE_NAME strips off the project_name/, leaving branch.
I want to get project_name.
I thought there might be something like this I could do:
environment {
NAME = "${env.JOB_NAME}.replaceAll(~/\/.*$/, '')
}
and then use ${NAME} later in the pipeline, but this doesn't seem to work
You can also do env.JOB_NAME - env.JOB_BASE_NAME and then drop one character off the end of that if you need to lose the final /.
Once you've defined something in your environment closure, it should be accessible not as a normal variable like NAME, but instead like the predefined env variables, such as env.NAME
I have two jobs which are pipelined, I want to send the BUILD_NUMBER info of upstream job to downstream.
The main point is we shouldn't trigger the downstream project. Triggering of downstream project should be manual.
Whenever I trigger the downstream job it need to get the latest BUILD_NUMBER of the upstream.
How can I do this?
Use environment inject plugin in the second job
As mentioned by #VnoC in the first job write the buildnumber in the properties file like below
echo "last_build_number = ${BUILD_NUMBER}"> ../Common.properties
Mention in the inject enviornement variable the same property file path for the secod job (Path is repective to the active workspace so keeping it in a common location)
Now is the second job you can access the variable like $last_build_number
You could set an environment variable, which will then be read by the next job with WithEnv(${last_build_number}) {...}.
That is not ideal since this is listed as an anti-pattern in Top 10 Best Practices for Jenkins Pipeline Plugin
While you can edit some settings in the env global variable, you should use the withEnv syntax instead.
Why? because the env variable is global, changing it directly is discouraged as it changes the environment globally, so the withEnv syntax is recommended.
Still, in your case, that could be an acceptable workaround.
environment {
last_build_number = ${BUILD_NUMBER}
}
I thought first to write it in a file, but the feature of reading parameters from a file is still pending (JENKINS-27413).