How to Setup Jenkins Pipeline Environment Variables(Tutorial)
How to Setup Jenkins Pipeline Environment Variables. Jenkins is an open-source automation server. It helps automate the parts of software development related to building, testing, and deploying, facilitating continuous integration and continuous delivery. It is a server-based system that runs in servlet containers such as Apache Tomcat. In addition, it supports version control tools, including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, ClearCase, and RTC. It can execute Apache Ant, Apache Maven, and sbt based projects and arbitrary shell scripts, and Windows batch commands.
Jenkins Environment Variable is a global variable exposed through the env variable and used anywhere in the Jenkins file. Any value stored in the env variable gets stored as a String type. Environment Variables can be set either at the pipeline top level, at the specific stage level, or inside the script block.
Another way of explaining Environment variables are like global key value pairs Jenkins can access and use in project. When using Jenkins environment variables we can avoid having to code the same values for each project. Other benefits of using Jenkins environment variables include improved security.
In this article, we will learn how to setup Jenkins Pipeline Environment Variables.
Listing Environment Variables
Let us start by listing all environment variables. Every Jenkins installation has this page called env-vars.html; if you open it in your Jenkins installation, you will see this list of environment variables with some short explanation. You can find variables like BUILD_ID, JOB_NAME, JOB_BASE_NAME, BUILD_URL, JENKINS_URL, and a few others.
Although it would not be the complete list, we can see some of these variables in the pipeline. Let us create a simple stage in our pipeline where we will call print and sort alphabetically. Then, we can apply this and run our pipeline to see the list of all available variables in that specific Jenkins instance.
pipeline{
agent any
stages{
stage("List env vars"){
steps{
sh "printenv | sort"
}
}
}
}
Accessing Environment Variables
To access the environment variables, we can add a new stage. We can start using env variables from the groovy interpreter site to pass a groovy string in an echo step, and I want to display the build number. So, in this case, we can use the groovy variable inside the groovy string and if you want to display BUILD_NUMBER.
pipeline{
agent any
stages{
stage("List env vars"){
steps{
sh "printenv | sort"
}
}
stage("Using env vars"){
steps{
echo "BUILD_NUMBER = ${env.BUILD_NUMBER}"
sh 'echo BUILD_NUMBER = $BUILD_NUMBER'
}
}
}
}
One thing worth mentioning is that the env. is optional. However, it is good practice to make this information explicit to know that this BUILD_NUMBER is expected to be taken from environment variables. Here we are using double quotes, so groovy will do its interpolation; its groovy variable will be interpolated in this place.
We can also use those env variables in the shell process. However, keep in mind that we want to use single quotes for simplicity because we want to do some echo like a BUILD_NUMBER, and we can access it with the ‘$’ sign. Therefore, there is no env prefix in the second line; as you can see, that is just shell environment variable access.
Setting Environment Variable
There are multiple ways to set the environment variables.
Setting Global Environment Variable
There is a block called environment, and we can put it at the top pipeline level. Any environment defined at this level will be available at any stage in this pipeline. For instance, if you want to define USER_NAME = Joe and USER_ID = 42. Now we can use these environment variables in any stage, say in the second stage.
pipeline{
agent any
environment{
USER_NAME = "Joe"
USER_ID = 42
}
stages{
stage("Using env vars"){
steps{
Echo "BUILD_NUMBER = ${env.BUILD_NUMBER}"
sh 'echo BUILD_NUMBER = $BUILD_NUMBER'
echo "Current user is ${env.USER_NAME}"
}
}
}
}
One thing that is worth mentioning is when it comes to setting environment variables. Every environment variable is always cast to string. So even though we set 42 as an integer value, the USER_ID is a string value. You can run the following code to check the type of environment variable:
pipeline{
agent any
environment{
USER_NAME = "Joe"
USER_ID = 42
}
stages{
stage("Using env vars"){
steps{
echo "BUILD_NUMBER = ${env.BUILD_NUMBER}"
sh 'echo BUILD_NUMBER = $BUILD_NUMBER'
echo "Current user is ${env.USER_NAME}"
echo "Current user id is ${env.USER_ID} type: ${env.USER_ID.class}"
}
}
}
}
Setting Stage Level Environment Variable
We can define the environment block at the stage level. For example, if we want to define the user path of Joe, we can do it as follows:
pipeline{
agent any
stages{
stage("Using env vars"){
environment{
USER_PATH = "/home/joe"
}
steps{
echo "Current user path is ${env.USER_PATH}"
}
}
}
}
Next with how to Setup Jenkins Pipeline Environment Variables the guide explains another way to set the environment variable. It is by using the env variable directly in the script block. We can define, let us say, USER_GROUP and display it. You will see that the underlying shell also has access to this environment variable.
pipeline{
agent any
stages{
stage("Using env vars"){
steps{
script{
env.USER_GROUP = "users"
}
sh 'echo Current user group is $USER_GROUP'
}
}
}
}
You can also set an environment variable using withEnv block. We can define a list of environment variables as strings.
pipeline{
agent any
stages{
stage("Using env vars"){
steps{
withEnv(["USER_PWD=secret", USER_IS_ADMIN=false]){
echo "Current user password is ${env.USER_PWD}"
sh 'echo Current user is admin? $USER_IS_ADMIN'
}
}
}
}
Overriding Environment Variable
We can override environment variables, but there are some limitations to it. Any variable defined in the pipeline environment block can be overridden in the local stage environment. We can check this by overriding the USER_ID to 32, and this variable will override the variable from the pipeline level environment.
However, if you try to override USER_NAME with script block and direct access to the env variable to “Adam,” it would not work. We can see it by moving the echo command for USER_NAME.
pipeline{
agent any
environment{
USER_NAME = "Joe"
USER_ID = 42
}
stages{
stage("Using env vars"){
environment{
USER_ID = 32
}
steps{
echo "Current user id is ${env.USER_ID} type: ${env.USER_ID.class}"
script{
env.USER_NAME = "Adam"
}
echo "Current user is ${env.USER_NAME}"
}
}
}
}
There is one way to override any variable, and this is with the withEnv block. So, for instance, if we define USER_NAME to Bob, we could see this new user name. But of course, its scope would be limited because this USER_NAME “Bob” exists only in this specific scope.
pipeline{
agent any
environment{
USER_NAME = "Joe"
USER_ID = 42
}
stages{
stage("Using env vars"){
environment{
USER_ID = 32
}
steps{
echo "Current user id is ${env.USER_ID} type: ${env.USER_ID.class}"
withEnv(["USER_NAME=Bob"]){
echo "Current user is ${env.USER_NAME}"
}
}
}
}
}
Also Read
Using Environment Variable as Boolean
Next section of how to Setup Jenkins Pipeline Environment Variables is when we know every env variable is of string type, we need to be careful to store Boolean. For example, we want to control the execution of the next stage with some env variable; we can call it TRIGGER_NEXT. Then we will add a new stage, “something” when the block uses expression to define if this stage should be executed or not, and we would execute it only if TRIGGER_NEXT is true.
We must use the toBoolean() command to convert the string “true” to a boolean value.
pipeline{
agent any
stages{
stage("Something"){
when {
expression{
env.TRIGGER_NEXT.toBoolean() = true
}
}
steps{
echo "OK!"
}
}
}
}
How to Setup Jenkins Pipeline Environment Variables Conclusion
After reading this tutorial, you should be able to setup Environment Variables , list and Access variables as well as use the variable as Boolean.
Jenkins can help you deliver a flawless final product on schedule when working on multiple projects.
