Here's the use case I have today.  We work on sprint branches in our SCM.  As we advance sprint to sprint we change the branch name. To handle this we set a global variable (SPRINT_BRANCH) with the branch name as its value.  Jenkins jobs designed to always focus on the "current sprint"  use that global variable ${SPRINT_BRANCH} as the branch name in the SCM checkout.  Elsewhere in Jenkins, using this variable works with the plugin SCM operations. This pattern allows us to migrate any number of jobs from one branch to the next by simply changing the value of SPRINT_BRANCH.  With Pipeline, a variable can not be used as the branch name.  

Is this Epic related to JENKINS-28921?

deepchip No. This EPIC is only about EnvInject, global variables feature is a part of the core

I'm curious if work is still underway on this epic. I'd like to push my work to make urltrigger work with pipelines upstream, but that work is blocked on this epic.

Hi oleg_nenashev, I don't think I am missing anything. Thanks for addressing this! I have now posted two pull requests in order to add pipeline support to the URL Trigger plugin, using envinject-api 1.2 in order to do so.

Unfortunately I will not have time to work on EnvInject issues for a while. I decided to unassign all issues so that somebody can take them and finalize.

Context: The plugin has been waiting for adoption for ~2 years. During all this time I was trying to keep this plugin afloat by reviewing the incoming pull requests, fixing defects and keeping the codebase up to date to simplify the handover. But I have not been using this plugin on my own so that such maintenance was a bit lame. I invite all active users to contribute to the plugin by taking ownership of this plugin and of EnvInject API. I am happy to provide any required knowledge transfers and do some assistance during the first months of maintenance

As per description, there are multiple workarounds. Can anybody put link to workaround page, or mention some workarounds here?

In pipeline "Properties Content",Path=$Path;$JAVA
bin;C:
Program Files (x86)\\PuTTY;C:\\NGS\\bin;C:\\Python27;C:
Python27
Scripts

$Path is not evaluated.

How to "Inject environment variables" using pipeline syntax?

I would like to see workarounds documentation.

Pass text-yaml variable to job:

like

EXTRA_VARIABLES_YAML:

variabl1: value1

then, merge extra data into job env:

def mergeEnv(envVar, extraVars) {
 try {
 def extraParams = readYaml text: extraVars
 for(String key in extraParams.keySet()) {
 envVar[key] = extraParams[key]
 println("Parameter ${key} is updated from EXTRA vars.")
 }
 } catch (Exception e) {
println("Can't update env parameteres, because: ${e.toString()}")
 }
}

 

extraVarsYAML = env.EXTRA_VARIABLES_YAML.trim() ?: ''
if (extraVarsYAML) {
mergeEnv(env, extraVarsYAML)
 extraVars = readYaml text: extraVarsYAML
} else {
 extraVars = [:]
}

What's the current workaround for this? I need to be able to inject env vars from a file in my pipeline script, whther its with this plugin or something else?

This should be closed and the plugin deprecated. There is nothing EnvInject offers to freestyle projects which you cannot already do in Pipeline.

mr_pablo I believe https://www.jenkins.io/doc/pipeline/steps/pipeline-utility-steps/#readproperties-read-properties-from-files-in-the-workspace-or-text may be what you're seeking.

The scenario I have, which may be similar to others, is to define a variable in the job configuration without causing side effects, such as prompting the user who triggers the build. I have automation in place to create build jobs, and I want the Jenkinsfile to utilize env.MY_JOB_VARIABLE as defined in the job configuration.

One example where I need this is with pipeline configurations that specify a subdirectory in the Jenkinsfile path. Unfortunately, the Jenkinsfile itself does not execute within that subdirectory. To work around this, I need to wrap stages with `dir("$JENKINSFILE_SUBDIR")` so that files are correctly located. Hardcoding job-specific configuration in the Jenkinsfile is not suitable due to my separation of concerns.

At present, I do not have a way to define a variable like `JENKINSFILE_SUBDIR` in the job configuration. And a reasonable scenario like having two Jenkinsfiles in one repo doesn't work.