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.
Related
So this is my entire Use case:
I have a parameterized build job which accepts file parameters. After the build I need to send a mail with that file and the size of the file. For this, I'm trying to add the name and size of the file as an Env variable using EnvInject Plugin.
But EnvInject is in the Build Environment step. The file parameter gets stored in the Workspace of the build only in the Build step, not in Build environment. So, there will be an error like File not found.
Due to which, I'm trying a crooked way of defining a properties file somewhere on my local system.I'm mentioning this properties file in "Properties File Path" of Inject Environment variables. In the build step I'm adding FOO=BAR and other values in the file so that I can use those values as my env variables down the line, like when I configure my e-mail template in Post Build Actions.
Can this process be done easily? I was initially making the properties file in JENKINS_HOME. I just got to know that I'm not allowed to do that as in master-agent architecture, JENKINS_HOME will be different and build will fail.
PS-1. The workspace gets deleted after every build
2. Any other plugins which can be used? If possible, please suggest without installing some new plugin as I'm not Jenkins admin
One way of solving this problem is by creating 3 different jobs as follows -
job 1 --> should call below 2 jobs(job 2 & job 3)
job 2:
Build --> Trigger/call builds on other projects --> job 2(block until the triggerred projects finish their builds)
select"Build on the same node" from Add Parameters.
job 3:
Build --> Trigger/call builds on other projects --> job 2(block until the triggerred projects finish their builds)
select"Build on the same node" from Add Parameters.
Job 2 (Create this job as follows):
Execution API --> using "GET_FILE" option you can download the required details on to the current working directory of your job.
Execute shell -->
now within "Execute Shell", download "consoleText" using wget command.
process the "consoleText" using unix command prepare a key-value pairs and store it under /tmp folder. i.e. "/tmp/env.prop"
Job 3 (Create this job as follows):
Bindings:
select "Inject environment variable to the build process" and under 'Properties File Path' enter "/tmp/env.prop"
now you can use the variable which you created in Job2 in the current job without any issue.
please note that it is important to select "Build on the same node" in Job 1, because this will preserve the data and it allows other jobs to access this information.
Let me know if its not clear.
I have a Jenkins pipeline job that builds my project using gradle. As part of the build i would like to use a global variable I have set in the build.gradle file
project.ext.set("MyVar", "My Value")
How can i access this variable in the pipeline build, so
myVar = varSetInGradleBuild
Hope that makes sense
Thanks
Well, usually dependency is reverse, Jenkins sets variables for build to control behavior with -P key.
For your use case you can define variables in gradle.properties file and read it in Jenkins pipeline.
I am using Promote Build plugin in Jenkins .
I need to take the approver information from the user in Jenkins and provide him the approval rights .
Here is what I am trying to do :
Is it feasible ?
Don't think you can use variables there. However, you could skip that condition, and instead have an Execute Shell build step, and there check for variables $PROMOTED_USER_NAME. Parse the name, and make your decision based on that.
Parent parameters don't automatically get passed to Promoted builds. However, you can export them to file, archive the file (important to archive as opposed to keep it in workspace), bring the file over in the promotion step, and either load it to environment variables with EnvInject plugin, or simply use the file as is in a script
On Parent Job
Configure parameter approverid
Have an Execute Shell build step with the following:
echo approverid=$approverid > myfile
At the end, make sure to Archive myfile
On Promotion Configuration
Skip the approval criteria
Add Copy Artifacts from another project step
For Project Name, use $PROMOTED_JOB_NAME
For Which build, use Specific Build, then provide $PROMOTED_NUMBER
For Artifacts to copy, use myfile
Add Inject Environment Variables build step
For Properties File Path, enter myfile
Add Execute Shell build step
In that shell, compare values of $approverid and $PROMOTED_USER_NAME
If they match, continue, else abort/exit promotion.
Or course, the history of execution (and abort) will be noted however.
Parameterized variable are not getting updated in jenkins
I m using the conditional build-step plugin to update the jenkins job parameter by executing shell script its showing me the new value of variable as well but its not get reflected.
You can try 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 "variable=`value`"> env.properties
It will create the properties file in the job workspace directory.
env.properties
In shell script:
"$variable"
If I understand correctly, you are trying to change the value of a pre-defined parameter
from within a script that is run by the job.
This will not work, because of "scope" (or "call-stack"),
as a process (your script) cannot change the environment of a parent process (your Jenkins job).
I have a Jenkins job that is doing the following (amongst other things):
Read user input for ENVIRONMENT and SERVERTYPE
Inject environment variable AGENT (initially blank) as a build step to create
a new variable
Execute shell as a build step to populate AGENT, based on what was entered
in ENVIRONMENT and SERVERTYPE
Use AGENT as an input to a plugin as a post build action
The problem is that the value of AGENT doesn't seem to persist outside of the "execute shell" build step. When I try and pass it into the post build action plugin, it's still blank.
Can anyone point out what am I doing wrong? I have read the documentation, but can't seem to figure it out.
Your problem is that whatever variables you set in the shell script, they don't make it out.
This is true for any process: child process (your shell script) can never directly affect environment of parent process (Jenkins executor client).
If you need the data to persist, you need to store it outside the script; there are many options like uploading it to a server or storing it in a database, the most obvious and easiest option is to save it to a file.
You can even save the value to a "properties file" in the syntax supported by EnvInject and specify path in "Properties File Path" field.
You need to populate properties file with the values of the environment variables to be injected again, so they will survive until post-build actions. The properties file usually resides in the job's workspace.
For example use the following steps:
Build step "Execute shell" :
AGENT="My agent"
echo AGENT=$AGENT > my.properties
Build step: "Inject environment variables",
Field "Properties File Path":
$WORKSPACE/my.properties
Post-Build Actions: "Editable Email Notification", Field "Default Content":
Current Agent $AGENT
Or ${ENV, var="AGENT"}