How to inject environment variables to a pipeline from another job jenkins - jenkins

So I have two jobs, one job creates a .properties file, and builds the second job (which is a pipeline) by using this option:
Here I specify a properties file to pass into the pipeline. What I don't know is what settings to put into the pipeline to "inject" these parameters.
The pipeline has no parameters to begin with. I want to inject those from the properties file into the pipeline. Usuaully I would use the inject enviroment variables plugin but I do not see it here. I don't think it is supported with pipeline jobs.
How do I input these paramaters into the pipeline, and how would I call them? ${env:param}, env.param?
Thank you

Assuming you are using an actual Properties object, this should work:
Set propSet = properties.entrySet()
propSet.each {
def key = it.getKey()
def value = it.getValue()
env."${key}" = value
}
Now you can access them directly in your build using the property name.

Related

How can I pass a list of parameters to Jenkins from a file

I need to pass a list of parameters to Jenkins from a file written in this way
param1=test1
param2=test2
paramBool=true
....
How can I pass these parameters?
I have to use the parameters in a Jenkins pipeline
I mentioned before a dynamic declarative pipeline parameters.
You might combine it with:
either readFile
or load, which can evaluate a Groovy source file into the Pipeline script, and modify params.

How to add to existing properties in groovy script?

I have a dsl file in which properties such as log rotator and parameters are being defined for a jenkins job. However, I want to add a property to the jenkins job in a groovy script. I do this by putting
properties([pipelineTriggers([githubPush()])])
in the corresponding groovy script. However, this overwrites all other parameters and properties as defined in the dsl script.
What I have right now is putting all properties in the dsl script in the groovy script as well but that causes two different places where developers need to change the properties. Is there a way in groovy to simply add a new property instead of overwriting the old ones.
Something like
properties.add([pipelineTriggers([githubPush()])])
would be very helpful.

Trigger Jenkins Job for every parameter

I have created a Global choice Parameter using Extensible Choice Parameter plugin.
I am using this parameter list in one of my parametrized jenkins job.
Is there a way in jenkins, where I can execute the job with each of the parameters in the Global choice Parameter list?
I have had a look on Build Flow job in jenkins, as suggested in this answer, but it seems it accepts hardcoded parameters only, and not dynamic.
I finally managed to resolve this using the following steps (with great help from this post) -
As my parameters list is dynamic in nature, it could be added or modified according to other jobs, we have managed it in a text file.
Next, We have used Extensible Choice Parameter plugin to display the parameters, using the groovy script -
def list = [];
File file = new File("D:/JenkinJob/parameterList.txt")
file.eachLine { line ->
list.add("$line")
}
return list
Now I want to call this jenkins job for each of the parameter.
For this, I have installed, BuildFlow plugin, and crated a new jenkins job of BuildFlow type -
Next, get the Extended Choice Parameter plugin, and configure it as follows -
Now in the flow step of this job, write this script, where "Feature" is the parameter, that is just created above, and within call to "build" parameter, pass in the name of job which we want to call for each parameter -
def features = params['Features'].split(',')
for (feature in features ) {
build("JobYouWantToCall", JobParameter: feature,)
}

seed job does not passes environment variable to groovy dsl script

I am using job-dsl-plugin. In my seed job 'a' I am setting a build environment variable using 'Inject environment variables to the build process' option and providing an environment variable as follows in 'Properties Content' :
SERVERADDRESS=abc
Now, the same seed job is also processing job DSLs as follows in 'Build' section as follows:
Look on Filesystem = enabled
DSL Scripts = **/*.groovy
Action for removed jobs = Ignore
Action for removed Views = Ignore
now, the above included groovy scripts is creating another job 'b' in which I am trying to access the 'SERVERADDRESS' variable value as follows:
goals('-DserverAddress=${SERVERADDRESS}')
but the above variable I cannot access in my groovy script. I can access standard environment variable for e.g. JOB_NAME, BUILD_ID, BUILD_TAG etc. in job 'b' but the custom variable (SERVERADDRESS) which I defined in job 'a' is not accessible.
Is there any way by which we can access custom defined variables in seed jobs to child jobs created by seed job?
If you are using envInject just for setting custom parameters (instead of injecting file with parameters), use 'This project is parameterized' option in your seed job and set the parameters there.
You can get those variables with binding.variables.get('<your variable name>')

How to pass parameter to the downstream job but shouldn't trigger the downstream job?

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).

Resources