To export environment variables as a metadata in your binary repository

Build Causes

This plugin also exposes the cause of the current build as an environment variable. A build can be triggered by multiple causes at the same time e.g. an SCM Change could have occurred at the same time as a user triggers the build manually.

Examples

Append to PATH on Windows

Warning!

This screenshot is from an older version of EnvInject. Starting with EnvInject 1.93, any backslashes (such as Windows directory separators) in environment variables should be escaped (doubled). (See JENKINS-31573.)

Additional features provided by other plugins

Extensibility with other plugins

EnvInject captures build environment variables populated by plugins providing environment variables through Jenkins extension points (such as BuildWrappers, EnvironmentContributions and so on). Environment variables injected by the EnvInject plugin are available in Jenkins triggers (for example in all XTrigger plugin typologies, injected environment variable can be used). Injected environment variables with the EnvInject plugin are captured by the BuildContext capture plugin.

Comparison with other plugins

This plugin is an alternative to Setenv Plugin and Envfile Plugin plugins Note 1: The EnvInject plugin automatically migrates the Jobs configuration from these plugins. The setenv and/or the envfile plugins can be deleted from your plugin list. Note 2: Master and slave are managed.

Known incompatibilities

Jenkins Pipeline

Even though it is possible to set up the EnvInject Job Property and build step in Pipeline, the plugin does not provide full compatibility with Pipeline Plugin.

Supported use-cases:

Injection of EnvVars defined in the "Properties Content" field of the Job Property

These EnvVars are being injected to the script environment and will be inaccessible via the "env" Pipeline global variable

All other use-cases of the plugin may work incorrectly in Jenkins Pipeline. Please see JENKINS-42614 for more information about unsupported use-cases. There is no short-term plan to fix the compatibility issues though any pull requests to the plugin will be appreciated.

Mask Passwords Plugin

MaskPasswords plugin is able to mask password elements. However, technically, this plugin provides its own class.

And we don't want to have a hard dependency from the EnvInject plugin to any other plugin. Therefore, EnvInject can't retrieve information from the MaskPassword plugin. However, EnvInject provides all MaskPasswords features.

Tool Environment Plugin

EnvInject can't use exported environment variables provided by the Tool Environment plugin. Instead, we suggest to use the SharedObjects Plugin. It covers Tool Env plugin features and provides a good integration with EnvInject.

Known limitations

As into regular shell scripts, you are not able to use "." character for environment variable names

Only previous environment variables are available for polling Some plugins provide polling mechanisms (such as SCM plugins, XTrigger plugins, ...) and you want to use injected environment variables in form fields of these plugins. Unfortunately, injected environment variables are processed only at build time therefore after the build is scheduled. Therefore, we can't access environment variables configured within the job. However, previous injected environment variables (from the previous build) are retrievable (implemented for example in the XTtrigger plugins). For the other plugins, authors are free to add the envinject-lib library dependency in their plugins in order to provide the ability to use environment variables given the EnvInject plugin.

1.6

1.5

1.4

* Fix portability in the history build.xml file (using the build reference instead of the absolute path of the EnvInjected file) * Add the ability to load a properties file at node startup (at master and/or at slave startup)

0.9

* Fix partially JENKINS-10847 and JENKINS-10845 - Enivronment is not separated * The ability to 'Keep system variables' has been removed. The feature will be restored later (and moved at slave/node level (not at job level).

Yes it is possible to substitute environment variables in text value.
However, ${BUILD_TAG} was not available.
I added in version 0.6, a 'Keep Jenkins build variables' option aimed at providing these kind of variable.
You have to check this option for your need.

There seems to be a problem with this plugin. When values are injected as a build step WHEN THE JOB IS RUN ON A SLAVE, it also sets the variables for all future jobs run on the slave. In addition, it strips away all the normal user/system variables and only displays on the Jenkins, job and injected variables.

Yeah - I can see checking all variables. It just comes as a bit of shock when standard Jenkins variable suddenly disappear after installing a plugin. I could see them disappear after using the plugin in a job, but after installation?

As it is, I grabbed v11 you referenced in one of the defects and it passed all the tests I had for it. This plugin in is pretty powerful - it's the closest thing there is to conditional control within a job. I suspect that even if conditions are added to build steps, we'll still need this plugin to control the variables that build step conditionals will probably check for.

At least for me, any file that I use is generated during the build. So being able to edit the file at design time is useless because the file doesn't exist. Also, you could use the Environment Properties Content to do away with a file entirely.

The plugin already enables you to provide variables in the job configuration UI (fill in the textarea with key/value pairs) : please look at the screenshot.
Moreover, the plugin enables you to also inject variables from properties file.
Therefore, one feature of the envinject plugin is to provide an hybrid between the setenv plugin and the envfile plugin.

I fully understand the current functionality. What I was requesting is something more than what is currently available: To be able to store in a properties file, env vars editable in a textbox in the job config UI.

It's very valuable to have those env vars stored in a file but the big problem with having them in a file is that they are not visible to someone who looks at a job's configuration from the Jenkins UI. They are also not as easily editable.

I would even be happy just to be able to see, in read-only mode, the env vars configured in a given file.

Is it clear that what I need is not covered by the current versions of envfile, setenv or envinject?

I'm hoping the file can be shown inline and that it can be edited from the config UI. However, I understand why technically those desires are problematic. For example, it could be tricky if one uses in a job configuration the envinject plugin both during a build's main steps and during promotion steps, referring the same properties file. This is actually exactly what I need to do.

I've trying EnvInject plugin, but I've found one problem. I'm developing a plugin for ACM access, and while I can access new defined environment variables from an AbstractBuild objects in checkout and calcRevisionsFromBuild, I'm not so lucky in the Polling process, compareRemoteRevisionWith method where I don't have an AbstractBuild object but an AbstractProject where I can do project.getLastBuild(). The problem is that injected variables are not persisting so when I retrieve the environmet of the last builds, new variables are not present. Is there a way to have access to variables injected in previous builds?

Well, very interesting "unifying" plugin. Thanks.
But... I would like to inject a file with a path defined with a variable set as an instance global property.
The configuration is as follows
For sure, I have checked that the value is correcty set.

The EnvInject plugin is not only an aggregation of the sentenv and the envfile plugin.
It provides more features such as the ability to prepare an environment by injecting variables and executing setup scripts.

For your use case with global properties, it was a missing feature. It wasn't taken into account. I fixed it.
Please upgrade to version 0.21 and use ${JENKINSVAL_DATAPROPS_PATH}.

1. It seems like the PATH variable is inaccessible in the "Properties Content" section

2. I'm having trouble accessing the variables I set in "Properties Content" in "Environment Script Content". It's unclear to me what the correct syntax for dereferencing the variables should be. Is this block of code done using the system shell? I'm using a Windows machine.

Thanks for using the plugin.
1) Did you try $PATH or ${PATH}?
2) Could you try the latest version (0.26). It should solve your issue.
If your problem persists, could you fill in a ticket in the Jenkins issue tracker for the envinject component?
And make sure you attach your job configuration file (config.xml) so that I can try to reproduce the problem.

I have problem with new plugin 1.5/1.6 (1.2 works well) on slave (linux) node. I've tried this plugin using "Inject environment variables to the build process" in "build environments". I used cmakebuilder plugin (not significant). Although a building process fail with cmake errors It is probably error in EnvInject plugin 1.5 version because the building process in 1.2 is ok. Bookmarks "Injected Environment Variable" in 1.2 contains environment variables from linux (slave), but 1.5/1.6 contains environment variable from windows (master). Thanks!

First, many tx for this plugin as it solves an issue I had with having the environment defined in time for the execution of the Release plugin. Now it works! :-)

Is there a way to run a script to "calculate" a value before the build and save it in a variable/property that is available throughout the build? What I am asking for is something like an extension to the Environment Script Content box where commands could be executed not only to create folders and so on but also to dynamically assign a value to a property that would be accessible to subsequent build steps. Is it possible today? If so, can you show how?

As a build step, you can execute a script creating a properties file and then inject the properties file in a next step by the EnvInject plugin (EnvInject plugin provides a build step named 'Inject environment variables for your job).
However, at the moment, you can't execute a script at the begining of the job that fills in a properties and injects it after.
For this request, I have to process the properties section after the script section.
Please could you raise an enhancement in the Jenkins issue tracker for the 'envinject' component?

Please could you try the version 1.8?
Execute a script executing your mapping drive and fill in a properties file.
Then load this new created properties file in the properties section to get the properties variables.

I don't know if it's easy or not (or even impossible) but one great additional feature would be the ability to set environment properties from the parameters default value defined in some other job.

The great advantage of this approach is that it would make it unnecessary to mess with some file. By using some fake job, I would be able to specify some parameters and default values that I could use in any job thanks to this plugin.

In my opinion, a job has to be executed in isolation from other jobs. Therefore, I don't like the idea to reuse some configuration elements from other jobs, except if it is a template job.
For the EnvInject plugin, you can load global properties file from the node.
Does it suit you?

During a Release build (via the Release plugin) I need to run additional steps where I need to make calls to tools that were auto-installed, such as Git and Maven for example. The Tool Environment plugin (https://wiki.jenkins-ci.org/display/JENKINS/Tool+Environment+Plugin) is very useful in that it sets an environment with the location of the wanted tool and I make good use of this during a normal build. My problem is that this plugin runs too late in the context of the Release plugin and I am left out luck as to knowing the location of the automatically installed tool(s). I was hoping the EnvInject plugin could come handy as it runs much earlier in the build process and in fact in time for the Release plugin, but there does not seem to exist an easy way to extract the location of those auto-installed tools again.

Would you be able to suggest a way to do this? Or maybe do you see this as a useful addition to the plugin instead?

I made a new plugin for this feature: the shared objects plugin.
This plugin makes it possible to share objects in Jenkins. At the moment a shared object can be a public file path, a Clearcase object path or a native tool installation.
Each object is propagated in the job as environment variables.

Is it possible that the variables aren't injected at post-build time when Sonar executes? No matter what I do it seems that Sonar always runs despite the value of the variable I specify in the "Skip if environment variable is defined" field. However, it works correctly and as expected if I specify a variable that is a build parameter instead of a variable injected by the EnvInject plugin.

I have master/slave setup, and my project has the ability to execute builds in parallel, i.e. I have 'Execute concurrent builds if necessary' option turned on.

But when I'm trying to inject any environment variables into my job ( 'Inject environment variables to the build process' option ), then the $WORKSPACE variable is NOT defined properly for parallel builds.

I'm not sure how the variable is handled but I don't have "'Execute concurrent builds if necessary'" enabled and I still see workspaces defined with @2, @3, @4, etc... Is there a way to stop this from happening?

Can I use this plugin to inject a variable containing downstream jobs, which I can use during a build action or a post-build action? Before I upgraded my Jenkins installation I was able to do this during a build action, but now I can't. Was that a bug or was I just lucky for a moment ;)

Yes.
You can't use mask-passwords plugin and envinject plugin together.
However, EnvInject plugin enables you to define global passwords and these passwords can be injected as environment variables and they are hidden in the Jenkins log, in the exported envinject variables section, ...

Waiting for the add of password per job, you can use password parameters given them a default value.
Password parameters are managed by the envinject plugin (parameters will be injected as environment variables, password parameters are hidden in the envinject reporting page, ...)

At 1.38, all our jobs are pretty much broken because our jobs are inheriting the environment from Jenkins Master.

So we rolled back to 1.35 where our jobs were passing (we can confirm that we are at 1.35 by going to Manage Jenkins->Plugins) , but they are still exhibiting the same behavior as if we were still at 1.38!

What do we have to modify/remove to get our Jenkins master back to the state that it was at? Does this plugin tweak the job's config.xml? Or are there some files that we have to manually delete to get it back to its original state.

I'm having trouble getting the P4_CHANGELIST variable. It appears that the variable isn't usable in the 'build environment' or the 'build step' inject sections. It appears that both of these should be executing after the scm steps. I set the 'Keep Jenkins Environment Variables' and the 'Keep Jenkins Build Variables' with no success. Are there other settings I need to toggle to preserve environment variables for after the SCM steps?

If I check the variable during a shell command build step it appears to be set correctly:

We just tried using the EnvInject plugin to set a computed environment variable within a particular job only, on an "opt in" basis. The intention was for the plugin not to affect any other jobs in any way. However, one of our Scons builds has suddenly started failing with missing environment variables which had previously been set successfully on the command line:

e.g. cmd VAR1=xxx VAR2=yyy

The obvious conclusion is that activating the EnvInject plugin immediately changes Jenkins' global behaviour in an extremely unwanted way, and unless we can get the previous behaviour back then we're going to have to throw this plugin away. Can anyone suggest what the plugin is doing and how we might fix it, please?

I'm trying to use a properties file with a single key which has it's values spread over multiple logical lines. I use the key as a list of jobs to trigger using the Jenkins Parameterized Trigger plugin (v2.15) however it tries to trigger a job called \ rather than ignoring it and stops triggerning jobs after the first \. It works ok if I remove all the \ characters and leave it as a single line, but with a list of 20 jobs it becomes difficult to read and update the properties file and my developers prefer using the logical lines. I'm not sure if this is an issue with the EnvInject plugin or the parameterized trigger plugin.

I've been setting up a number of builds that require different path environment variables and I decided to give this plug a try. The thing is, I'm not getting the path variable that I set in "Prepare Environment for Run" when I run build steps with a shell script or a windows batch file. I tried to echo the path as a build step and the result is the original system path, despite the fact that I have set replacement values as well as checked in the node configuration to unset system variables. Is there some other step that I would need to do?

I defined a Groovy script in "Prepare environment for run" to set some environment vars based on a parameter value, which are subsequently evaluated.

This works well with "Free Style" build jobs. However, if I the job type of the main job is "Build Flow" the script does not seem to be evaluated as I don't see any log message saying so and the environment variables do not exist in the jobs I call from there.

Is this an error in EnvInject? Or in BuildFlow?

If Build Flow is not supported the EnvInject Options should not appear there.

At the moment, Envinject plugin doesn't work for a job type of Build flow.
This issue relies on the build flow plugin.
Please report an issue for the build-flow component.
However, defining new job type is always a big deal and need for this new type to handle proprely all plugins.
And with the large Jenkins plugin ecosystem, we have difficulty to handle that.

So far, so good. I am passing a gitish along the pipeline and building from a detached HEAD. At the start of my job I set an environment using EnvInject, and it is working as advertised, and none of the features in the Build Pipeline plugin are being interfered with.

Trying to represent my job pipeline with Build Pipeline didn't work for me, although seemingly for other reasons than with BuildFlow.

I defined a start job, that only sets some environment variables via a groovy script. In the downstream jobs I do find a list of "Injected environment variables", however those set by the start job are missing.

We're using Config File Provider which sets an environment variable to the path of the file it provides, however that value doesn't seem to carry over in EnvInj and results in an "unresolved variable" error. It's the same behavior that I get with ToolEnv if I don't activate ToolEnv in "prepare environment for run", so I assume it's because Config File Provider isn't EnvInj aware.

My questions are: Is my diagnosis correct, and ConfigFileProvider should be changed to be compatible with EnvInj? If so, can you give me some directions in terms of what the change in ConfigFileProvider should be to help EnvInj use it's file path variable?

Jenkins enables you to define build parameter with spaces.
However, I think it is a mistake because it is not allowed in environment variables names.
Remember that EnvInject plugin (through properties and other elements) enables you to control environment variables for the build.
Therefore, you can't define properties with spaces for the EnvInject plugin.

Is there a way with a groovy script to return variables which should be considered as passwords?

For example, I have a groovy script that returns the variables:

user=username
password=password_of_the_user

But password are show in clear text at injected variables.

It should be great that the plugin would inject a variable starting with encrypted. (or another prefix) as a password variable, so at Jenkins Injected Environment Variables it should appears encrypted.

user=username
encrypted.password=password_of_the_user

At previous example, user is injected in clear text, but password should be injected as a password (encrypted.password), so it's clear value is available at build process, but at logs and screens it should be showed encrypted.

It could be a great idea. However, I have difficulty implementing this new feature with the current code for now. At the moment, the design is too complex.
In addition, if you look a the Password parameter, it is in plain text in the Jenkins log.
Therefore do you want the same behavior as job password parameter.

I am using EnvInject 1.85 with Jenkins ver. 1.512 and I found that when EnvInject is installed I lost both LD_LIBRARY_PATH and PATH system variables from Linux master node, using Prepare jobs environment &/| Unset System Environment Variables made no difference at all, all other Environment variables I set on master config are ok

Thanks a lot, I see you already started working on 1.86, you are a star

I do not want to be pushing, but do you know when this will be available, I've tried to set PATH using different ways but could not, the only solution I had is to uninstall the plugin, which meant I lost its really powerful use

I hope this is the appropriate way to report an issue (if not, please tell me and I will do it differently).

After upgrading to Jenkins 1.521 it seems that this plugin is breaking the job configuration dialogs (they get stuck in Loading). Disabling just this one plugin resolves the issue (but of course I loose all the env inject goodness :-( ). The server is on Ubuntu 12.04 64 bit (doubt that is relevant). I am using Chrome 27.0.1453.116 on Mac 10.8.4. Getting the same with the latest Firefox, so this looks like a general issue. I am all current on my plugins (including this one) of course).

My javascript console shows:

Uncaught TypeError: Property 'on' of object #<HTMLFormElement> is not a function(textarea.js:18)

Is there anything else I can do to help diagnosing this issue? Any additional data?

Specifications of environment
master (Jenkins server) installed on Red Hat Enterprise Linux Server release 5.7 (Tikanga), Jenkins ver. 1.509.3
slave installed on Red Hat Enterprise Linux Server release 6.3 (Santiago)
Ver of plugin used is 1.89
Defined a variable LB_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/IBM/db2/V9.5/lib64 at the node level of the slave. prior to installing this plugin, was able to access LB_LIBRARY_PATH value from the node when running the job (verified by echoing the value of the variable during the job run). After installing the plugin, can no longer access the value from the node, even though not using the "Prepare an environment for the run" section.To work aroudn the issue, I needed to enable "Prepare an environment for the run" and then disable "Keep Jenkins Environment Variables" and "Keep Jenkins Build Variables"
Specifications of environment

:/opt/IBM/db2/V9.5/lib64* at the node level of the slave. prior to installing this plugin, was able to access LB_LIBRARY_PATH value from the node when running the job (verified by echoing the value of the variable during the job run). After installing the plugin, can no longer access the value from the node, even though not using the "Prepare an environment for the run" section.

To work around the issue, I needed to enable "Prepare an environment for the run" and then disable "Keep Jenkins Environment Variables" and "Keep Jenkins Build Variables"

The EnvInject plugin still does not override the global environment variable in within a jenkins job. I am using version 1.89.

I have set couple of global variables in the jenkins. In one of the jenkins job, I am trying to override the values of those variables based on a condition. But it is not working.

Below snippet is for reference:[EnvInject] - Loading node environment variables.[EnvInject] - Preparing an environment for the build.[EnvInject] - Keeping Jenkins build variables.[EnvInject] - Executing and processing the following script content: This piece is executed in the Prepare an environment for the run section.

I just wanted to note for other people who are migrating from the deprecated SetEnv plugin to EnvInject that I ran into an issue with formatting. The automatic migration did not work for me. On a windows slave I had to convert from bash syntax to windows cmd syntax.

Script File PathI have never used, but i think i can use batch-files as in the next sectionis the extension (*.bat, *.sh) fix or free?

Script Content
I use batch contents like above
echo %WORKSPACE%
if "%WORKSPACE%"=="" exit 1but i have seen samples for shell scriptwhat is the used script language?Batch? Shell? is OS-depended Window=Batch an d linux=shell?

Evaluated Groovy script
i have never used it so I think grooy scripts will work

I am trying to use this to inject the version information from a pom.xml. I am doing this from a non-Maven job. I tried using this Groovy script to parse pom.xml. However, it appears that the job workspace is not the default folder. Can anyone shed some light on how to get the value of the workspace environment variable in this context:

I would like to add environment variables to “$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/",Is there any way？

（$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/api/json）

1. Plug-ins can not be used！Because I want to read real-time this environment variables.

2. jenkins-cli.jar set-env-variables [-s JENKINS_URL] can not be used ﻿﻿﻿﻿！Because only in the next "Execute shell" to read, and can not be added to “$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/".

I would like to add environment variables to “$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/",Is there any way？

（$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/api/json）

1. Plug-ins can not be used！Because I want to read real-time this environment variables.

2. jenkins-cli.jar set-env-variables [-s JENKINS_URL] can not be used ﻿﻿﻿﻿！Because only in the next "Execute shell" to read, and can not be added to “$JENKINS_URL/job/$JOB_NAME/$BUILD_ID/injectedEnvVars/".

Is there a way to silence the plugin so it doesn't display the script before executing it?EnvInject - Evaluation the following Groovy script content:
def map = EnvInject Plugin
..... rest of my script source ....

Oleg Nenashev I have both of those plugins installed as well as EnvInject, but when I add a "Flexible publish" as a post-build action, I don't see "Inject environment variables" as one of the available choices under "Add". Is there some additional configuration I'm missing in order to make this work?

In our deployment we use Git and have set "Additional Behaviours" → "Check out to a sub-directory" config. We have entered a Local subdirector and would like this available from a script/shell in the Build Section. Can this plugin achieve this?

Can this be used in pipeline projects, My intention is i have pipeline project which gets the script files from the git using "Pipelinescriptfromscm", this checks out the github contents in master node . My git contents has properties file and few jenkins file. For some reason even after giving Properties File Path : pipeline.properties

Properties Content : TESTENV=ENV1

in my pipeline jenkins file i can access env.TESTENV but i cannot access the any properties in the pipeline.properties file.

The same set up when i tried for the Free style project i could see the below logs but this is not happening for the pipeline jobs

I have a security warning in Jenkins (2.114) "Exposure of sensitive build variables stored by EnvInject 1.90 and earlier".

We have the list of plugins and versions of them stored in SVN (updated daily) so I can find that we updated to 1.92.1 since at least end of Nov. 2015. I check using find, that I don't have any "injectedEnvVars.txt" on my master, older than this date.

Still I get this error message. Can I silence it by solving the issue ? How ?Or do I simply need to disable the warning in Jenkins configuration ?(On one hand I don't like to just "click away" a security warning, on the other hand an irrelevant warning is just clutter)

I am trying to automate job duplication by using job's config.xml via jenkins cli. However, the resulting job has variables not properly entered in "Inject environment variables to the build process" like in example below. I am using v2.1.5 for environment injector.