I can see the same problem using Linux. Version 1.528 still have the same problem.

Which version of the nodelabelparameter plugin are you using?

I am using the latest one, version 1.4. The same applies to parameterized trigger plugin, version 2.19.

I'm not using the nodelabel plug in, I'm accessing ${NODE_NAME} as an environment variable.

I'm not able to reproduce this, can you please clearly describe how to reproduce this scenario?
Maybe you can use the recipe plugin to provide the configuration? https://wiki.jenkins-ci.org/display/JENKINS/Recipe+Plugin

Config JOB A

Hi, you are right, this was a tough one to reproduce because when I set up small demo jobs with a play-around Jenkins with node label parameters only it worked.

What is different at my "real" Jenkins:

• the upstream job uses a Label (clearcase) to find any machine with ClearCase installed
• the downstream job has a node label as parameter called HOST_NAME. The upstream job explicitely passes HOST_NAME as ${NODE_NAME}

I will try to attach the config.xml of my small demo jobs.

Config Job B

I wanted to work around the problem by setting the missing environment variable from the windows batch I execute. But it seems that this is not passed to the post-build trigger.:-/ Has anybody an idea how I could work around the problem?

IF "%NODE_NAME%" == "" GOTO NONODENAME

:YESNODENAME
@ECHO The NODE_NAME environment variable was detected.
@ECHO %NODE_NAME%
GOTO END

:NONODENAME
@ECHO The NODE_NAME environment variable was NOT detected.
set NODE_NAME=master
GOTO END
:END

That doesnt work this way.
Maybe a combination of 2 plugins will solve your problem:

Try adding ConditionalBuild plugin, add a conditional action using:
Execute Windows batch command / Execute shell as condition:

@echo off
if not defined NODE_NAME (
exit 0
)
exit 1

Then the conditional action will only be called in case of the environment variable is not defined.
As action you can try to use the envinject-plugin to inject a variable:
NODE_NAME=master

This should pass the injected variable to the post build trigger.

But i didn't tested this workaround...

Thanks Sven, that works! At least with my small test jobs.

I think this is related to JENKINS-19307 which is fixed with core version 1.532.1
my tests where OK with '1.532.1' - can you please try too?

Sorry for the delay, I have been on holidays.

I tried with 1.546 with my small test jobs I have attached to this ticket:
It doesn't work. JOB B states

pending #9 cancel this build (pending—All nodes of label ‘’ are offline) [LabelParameterValue: HOST_NAME=]

while staying in the build queue forever.

If this is only fixed in LTS with 1532.1, I have to re-test.

Just retested with 1.532.1, same result:

pending #9 cancel this build (pending—All nodes of label ‘’ are offline) [LabelParameterValue: HOST_NAME=]

I tried to recreate the issue with your config.xml's in a test case, but still everything is ok.
Can you please have a try with the newest beta version of the nodelabel-plugin?
https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin#NodeLabelParameterPlugin-1.5.0beta%2816.Jan2014%29

When reading all the comments on this issue, I'm not 100% sure if everyone has the nodelabel-plugin installed or if someone has the same issue without the nodelabel-plugin installed.

I pushed a branch with a testcase trying to reproduce this issue:
https://github.com/jenkinsci/nodelabelparameter-plugin/tree/JENKINS-19222

https://github.com/jenkinsci/nodelabelparameter-plugin/commit/df1fcdbd0db9a9fb3cec28e73cac5de32eb4b975

Sorry for the late answer, because I have worked around the problem on my production server and do not use the master for any serious builds anymore. But: The problem still persists with plugin version 1.5.1 and Jenkins 1532.2

Maybe this helps:
analysis-core 1.55 true false
ant 1.2 true true
build-timeout 1.12.2 true false
changelog-history 1.3 true false
changes-since-last-success 0.5 true false
claim 2.3 true false
clearcase 1.5 true false
clone-workspace-scm 0.6 true false
conditional-buildstep 1.3.3 true false
copy-project-link 1.2 true false
create-fingerprint 1.2 true false
credentials 1.10 true true
cvs 2.11 true true
depgraph-view 0.11 true false
disk-usage 0.23 true false
email-ext 2.37.2 true false
envinject 1.89 true false
Exclusion 0.10 true false
external-monitor-job 1.2 true true
groovy 1.15 true false
groovy-postbuild 1.8 true false
javadoc 1.1 true true
job-dsl 1.20 true false
jobConfigHistory 2.5 true false
jquery 1.7.2-1 true false
jquery-ui 1.0.2 true false
ldap 1.8 true true
mailer 1.8 true true
matrix-auth 1.1 true false
maven-plugin 2.1 true true
msbuild 1.21 true false
nodelabelparameter 1.5.1 true false
pam-auth 1.1 true true
parameterized-trigger 2.22 true false
PrioritySorter 2.6 true false
promoted-builds 2.15 true false
publish-over-cifs 0.3 true false
rebuild 1.21 true false
run-condition 1.0 true false
schedule-failed-builds 1.1 true false
scm-api 0.2 true false
sectioned-view 1.18 true false
show-build-parameters 1.0 true false
ssh-credentials 1.6.1 true true
ssh-slaves 1.6 true true
subversion 2.2 true true
template-project 1.4 true false
throttle-concurrents 1.8.1 true false
timestamper 1.5.8 true false
token-macro 1.10 true false
translation 1.11 true true
violations 0.7.11 true false
warnings 4.39 true false
ws-cleanup 0.20 true false
xunit

Trivial to reproduce: Just install envinject. (Jenkins 1.563, envinject 1.89).

Create a job, labeled 'master', just printing env vars in a Shell or Batch step. Build once. Install envinject. Build again. NODE_NAME is not present in the second build's output.

That plugin sucks so much (while being basically without alternative) it's inconceivable.

I can confirm I have this problem on jenkins 1.575 and indeed I also have envinject 1.89. Whichever plugin causes this, it would be nice to have it fixed.

Still occurs on 1.580 with Envinject 1.90; while the plugin is disabled, the environment variable NODE_NAME is set.

Updated issue title to match recent comments' information.

Looks like it's this code right here:

https://github.com/jenkinsci/envinject-plugin/blob/edfdceb87e012856ae9c777e1117aec310be5493/src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectVariableGetter.java#L41

Should probably look more like this:

https://github.com/jenkinsci/jenkins/blob/84c76253862a2f36f813a7aa45b77d99c1616be4/core/src/main/java/jenkins/model/CoreEnvironmentContributor.java#L57

I submitted a pull request that should fix this. https://github.com/jenkinsci/envinject-plugin/pull/39

Code changed in jenkins
User: Alex Earl
Path:
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectVariableGetter.java
http://jenkins-ci.org/commit/envinject-plugin/63389901c85ba6c1a903e25df5fe3f815e4c1b36
Log:
Fix JENKINS-19222

Make setting the NODE_NAME similar to what core does.

Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectVariableGetter.java
http://jenkins-ci.org/commit/envinject-plugin/4260b55f4cf0f89910fd61d0ae3a0cedbfeda3f5
Log:
Merge pull request #39 from slide/master

Fix JENKINS-19222

Compare: https://github.com/jenkinsci/envinject-plugin/compare/de93818b4007...4260b55f4cf0

I tried this again with the merged pull request from Alex Earl and the bug seems to be fixed on my end. In our case, our Perforce SCM configuration uses ${NODE_NAME} to generate workspaces for each machine - but polling was broken on the master.

Thanks!

Does anybody still see this issue?

This sounds like a manifestation of the more generic bug JENKINS-24283 - variables with empty values get unset.  I'd guess that fixing that one would fix this one.