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>')
Related
I seem to have found a bug with trying to pass environment variables from one Jenkins job to another.
I have a Jenkins job which contains a Powershell build step. My question is not about the Powershell script, as that does exactly what I want (it goes to Artifactory, finds a list of all the builds and then gets the build number of the latest one). The script ends up with the Artifactory build number as a text string '$LATEST_BUILD_NO_SLASH' (for clarity, this is not the Jenkins build number). This is eventually stored as an environment variable called 'LATEST_BUILD_NUM_VAL'
This is definitely creating an environment variable with my value stored in it, as it can be seen in the 'Environment Variables' list.
This environment variable is passed in the standard way in the parameterized build step.
My issue is that when I use this environment variable in a downstream build having passed it using 'LATEST_BUILD_NUM = ${LATEST_BUILD_NUM_VAL}', I get '${LATEST_BUILD_NUM_VAL}' as the value passed to the downstream job:
But, if I pass a Jenkins created environment variable i.e.'LATEST_BUILD_NUM = ${JOB_BASE_NAME}' I get the correct variable in the downstream job:
I have spent all day banging my head around this and don't really know where to go from here. I seem to be creating the environment variable correctly, as it is in the environment variables list and it works if I use a standard environment variable. I have declared 'LATEST_BUILD_NUM' as a parameter in my downstream build.
Is there any other way of achieving what I am trying to do?
I have checked in the 'Jenkins Issues' log for issues with parameterised builds and I can't find anything similar to my issue.
In case it is of any relevance, the Jenkins Environment Injector plugin is v2.1.6 and the Parameterized Trigger plugin is v2.35.2.
This is easy to achieve in Jenkins Pipeline:
Your second job (JobB) is called from your first job (JobA) as a downstream job. Thus somewhere, (probably the end of your JobA pipeline) you will have:
build job: 'CloudbeeFolder1/Path/To/JobB', propagate: false, wait: false, parameters: [[$class: 'StringParameterValue', name: 'MY_PARAM', value: "${env.SOME_VALUE}"]]
Then in JobB on the "other side" you have:
environment {
PARAM_FROM_PIPELINE = "${params.MY_PARAM}"
}
This gets the value of your parameter into an environment variable in JobB.
in first job in post build action--> Trigger Parameterized build on other projects select this
In that project build --> give name of downward jobname
select Add parameter in that add Predefined parameter give parameter in key value format e.g Temp=${BUILD_ID}
In second job select project is parameterized in select any option e.g string parameter and put name as Temp and used this parameter in shell or anywhere as $Temp ...
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.
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.
A custom plugin we wrote for an older version of Jenkins uses an EnvironmentContributingAction to provide environment variables to the execution so they could be used in future build steps and passed as parameters to downstream jobs.
While attempting to convert our build to workflow, I'm having trouble accessing these variables:
node {
// this step queries an API and puts the results in
// environment variables called FE1|BE1_INTERNAL_ADDRESS
step([$class: 'SomeClass', parameter: foo])
// this ends up echoing 'null and null'
echo "${env.FE1_INTERNAL_ADDRESS} and ${env.BE1_INTERNAL_ADDRESS}"
}
Is there a way to access the environment variable that was injected? Do I have to convert this functionality to a build wrapper instead?
EnvironmentContributingAction is currently limited to AbstractBuilds, which WorkflowRuns are not, so pending JENKINS-29537 which I just filed, your plugin would need to be modified somehow. Options include:
Have the builder add a plain Action instead, then register an EnvironmentContributor whose buildEnvironmentFor(Run, …) checks for its presence using Run.getAction(Class).
Switch to a SimpleBuildWrapper which defines the environment variables within a scope, then invoke it from Workflow using the wrap step.
Depend on workflow-step-api and define a custom Workflow Step with comparable functionality but directly returning a List<String> or whatever makes sense in your context. (code sample)
Since PR-2975 is merged, you are able to use new interface:
void buildEnvVars(#Nonnull Run<?, ?> run, #Nonnull EnvVars env, #CheckForNull Node node)
It will be used by old type of builds as well.
I am using an Environment Variable so that that it can be modified and Recipient List will consume that environment variable.
So this value is passed as a build parameter:
Followed to that I am modifying it. Just as an example:
Now I am accessing this value in the recipient list:
Unfortunately Jenkins is not able to get this new value. It is using the old value. How this behavior can be fixed?
We need to use the EnvInject Plugin. One of the features is a build step that allows you to "inject" parameters into the build job from a settings file.
Create a property for the email list in the env.properties file:
echo "email_list=`dummy#test.com`"> env.properties
It will create the properties file in the job workspace directory.
env.properties
In Recipient list access this variable using the following:
"$email_list"