Jenkins global env vars stuck for some slave jobs
Hi all,
We've been trying to use Jenkins global env vars to define the svn URL to use
for some of our builds. While this seemed to work when we tested it earlier,
now that we're trying to set the env var back from a release branch to the
trunk, the value of the env var seems stuck for some build jobs.
Our Machintosh full build has the old idea of the env var while our Windows
full build sees the new, correct env var value. Both of these jobs are run on
build slaves, not the Jenkins server. We're using Jenkins ver. 1.482.
Here's more details:
This is the env var is set in Configure System - Global properties -
Environment variables
name: FULL_BUILD_TRUNK_TO_USE
value: trunk
I've hacked our problematic Mac build job script to output what it thinks is
the value of this env var, then purposely error to stop the job. I've also
tried defining test env vars from the global one in the job itself and via the
env inject plugin as a test.
For the injected env var test, I've defined the following:
Build Environment - Inject environment variables to the build process -
Properties Content
INJECTED_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
For the build job env var test, I've defined the following:
Build Environment - Set environment variables
BUILD_ENV_VAR_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
Here's the hacked test build job script:
--snip--
#!/bin/sh
echo This is a hack to see what this build job thinks the build env var is set
to.
echo FULL_BUILD_TRUNK_TO_USE = ${FULL_BUILD_TRUNK_TO_USE}
echo INJECTED_TRUNK_TO_USE = ${INJECTED_TRUNK_TO_USE}
echo BUILD_ENV_VAR_TRUNK_TO_USE = ${BUILD_ENV_VAR_TRUNK_TO_USE}
exit 1
--snip--
In all cases, the above script code outputs the old branch value of
FULL_BUILD_TRUNK_TO_USE, not the new trunk value set in the global config:
--snip--
[EnvInject] - Executing scripts and injecting environment variables after the
SCM step.
[EnvInject] - Injecting as environment variables the properties content
INJECTED_TRUNK_TO_USE=branches/RB-2.3.1
[EnvInject] - Variables injected successfully.
[ClientMacFull] $ /bin/sh
/var/folders/uu/uu50uc60HNO7gmdeMNxMEE+++TI/-Tmp-/hudson2189251323725654867.sh
This is a hack to see what this build job thinks the build env var is set to.
FULL_BUILD_TRUNK_TO_USE = branches/RB-2.3.1
INJECTED_TRUNK_TO_USE = branches/RB-2.3.1
BUILD_ENV_VAR_TRUNK_TO_USE = branches/RB-2.3.1
--snip--
What's odd is that the Windows build does not have the same problem. However
one difference with that build is that the global env var is used directly in
the svn URL settings of that job, whereas the Mac build manually calls svn
directly from the script using the env var itself to build the URL. So the Mac
build script directly accesses the env var in the script and the Windows build
does not.
Any ideas as to what's wrong and how I can get this to work?
Thanks in advance for any suggestions.
Best,
Allen Cronce
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins global env vars stuck for some slave jobs
Try restarting your slaves. There was an issue with EnvInject where global
variable changes wouldn't propagate to the slave unless the slave was fully
disconnected and reconnected.
On Friday, January 17, 2014 8:19:34 AM UTC-8, Allen Cronce wrote:
Hi all,
We've been trying to use Jenkins global env vars to define the svn URL to
use for some of our builds. While this seemed to work when we tested it
earlier, now that we're trying to set the env var back from a release
branch to the trunk, the value of the env var seems stuck for some build
jobs.
Our Machintosh full build has the old idea of the env var while our
Windows full build sees the new, correct env var value. Both of these jobs
are run on build slaves, not the Jenkins server. We're using Jenkins ver.
1.482.
Here's more details:
This is the env var is set in Configure System - Global properties -
Environment variables
name: FULL_BUILD_TRUNK_TO_USE
value: trunk
I've hacked our problematic Mac build job script to output what it thinks
is the value of this env var, then purposely error to stop the job. I've
also tried defining test env vars from the global one in the job itself and
via the env inject plugin as a test.
For the injected env var test, I've defined the following:
Build Environment - Inject environment variables to the build process
- Properties Content
INJECTED_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
For the build job env var test, I've defined the following:
Build Environment - Set environment variables
BUILD_ENV_VAR_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
Here's the hacked test build job script:
--snip--
#!/bin/sh
echo This is a hack to see what this build job thinks the build env var
is set to.
echo FULL_BUILD_TRUNK_TO_USE = ${FULL_BUILD_TRUNK_TO_USE}
echo INJECTED_TRUNK_TO_USE = ${INJECTED_TRUNK_TO_USE}
echo BUILD_ENV_VAR_TRUNK_TO_USE = ${BUILD_ENV_VAR_TRUNK_TO_USE}
exit 1
--snip--
In all cases, the above script code outputs the old branch value
of FULL_BUILD_TRUNK_TO_USE, not the new trunk value set in the global
config:
--snip--
[EnvInject] - Executing scripts and injecting environment variables after
the SCM step.
[EnvInject] - Injecting as environment variables the properties content
INJECTED_TRUNK_TO_USE=branches/RB-2.3.1
[EnvInject] - Variables injected successfully.
[ClientMacFull] $ /bin/sh
/var/folders/uu/uu50uc60HNO7gmdeMNxMEE+++TI/-Tmp-/hudson2189251323725654867.sh
This is a hack to see what this build job thinks the build env var is set
to.
FULL_BUILD_TRUNK_TO_USE = branches/RB-2.3.1
INJECTED_TRUNK_TO_USE = branches/RB-2.3.1
BUILD_ENV_VAR_TRUNK_TO_USE = branches/RB-2.3.1
--snip--
What's odd is that the Windows build does not have the same problem.
However one difference with that build is that the global env var is used
directly in the svn URL settings of that job, whereas the Mac build
manually calls svn directly from the script using the env var itself to
build the URL. So the Mac build script directly accesses the env var in the
script and the Windows build does not.
Any ideas as to what's wrong and how I can get this to work?
Thanks in advance for any suggestions.
Best,
Allen Cronce
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins global env vars stuck for some slave jobs
Thanks. I just tried that (before seeing your email). It worked. The build
slave now has the correct env var value.
I guess that we can reboot as a work around. We don't change back and forth
between the trunk and branches that often.
But is there a more permanent solution? Maybe the problem you mentioned has
been fixed in an update?
On Friday, January 17, 2014 9:47:52 AM UTC-8, Jason Swager wrote:
Try restarting your slaves. There was an issue with EnvInject where
global variable changes wouldn't propagate to the slave unless the slave
was fully disconnected and reconnected.
On Friday, January 17, 2014 8:19:34 AM UTC-8, Allen Cronce wrote:
Hi all,
We've been trying to use Jenkins global env vars to define the svn URL to
use for some of our builds. While this seemed to work when we tested it
earlier, now that we're trying to set the env var back from a release
branch to the trunk, the value of the env var seems stuck for some build
jobs.
Our Machintosh full build has the old idea of the env var while our
Windows full build sees the new, correct env var value. Both of these jobs
are run on build slaves, not the Jenkins server. We're using Jenkins ver.
1.482.
Here's more details:
This is the env var is set in Configure System - Global properties -
Environment variables
name: FULL_BUILD_TRUNK_TO_USE
value: trunk
I've hacked our problematic Mac build job script to output what it thinks
is the value of this env var, then purposely error to stop the job. I've
also tried defining test env vars from the global one in the job itself and
via the env inject plugin as a test.
For the injected env var test, I've defined the following:
Build Environment - Inject environment variables to the build process
- Properties Content
INJECTED_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
For the build job env var test, I've defined the following:
Build Environment - Set environment variables
BUILD_ENV_VAR_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
Here's the hacked test build job script:
--snip--
#!/bin/sh
echo This is a hack to see what this build job thinks the build env var
is set to.
echo FULL_BUILD_TRUNK_TO_USE = ${FULL_BUILD_TRUNK_TO_USE}
echo INJECTED_TRUNK_TO_USE = ${INJECTED_TRUNK_TO_USE}
echo BUILD_ENV_VAR_TRUNK_TO_USE = ${BUILD_ENV_VAR_TRUNK_TO_USE}
exit 1
--snip--
In all cases, the above script code outputs the old branch value
of FULL_BUILD_TRUNK_TO_USE, not the new trunk value set in the global
config:
--snip--
[EnvInject] - Executing scripts and injecting environment variables after
the SCM step.
[EnvInject] - Injecting as environment variables the properties content
INJECTED_TRUNK_TO_USE=branches/RB-2.3.1
[EnvInject] - Variables injected successfully.
[ClientMacFull] $ /bin/sh
/var/folders/uu/uu50uc60HNO7gmdeMNxMEE+++TI/-Tmp-/hudson2189251323725654867.sh
This is a hack to see what this build job thinks the build env var is set
to.
FULL_BUILD_TRUNK_TO_USE = branches/RB-2.3.1
INJECTED_TRUNK_TO_USE = branches/RB-2.3.1
BUILD_ENV_VAR_TRUNK_TO_USE = branches/RB-2.3.1
--snip--
What's odd is that the Windows build does not have the same problem.
However one difference with that build is that the global env var is used
directly in the svn URL settings of that job, whereas the Mac build
manually calls svn directly from the script using the env var itself to
build the URL. So the Mac build script directly accesses the env var in the
script and the Windows build does not.
Any ideas as to what's wrong and how I can get this to work?
Thanks in advance for any suggestions.
Best,
Allen Cronce
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Jenkins global env vars stuck for some slave jobs
I believe that
JENKINS-14623https://issues.jenkins-ci.org/browse/JENKINS-14623 covers
this issue indirectly.
On Friday, January 17, 2014 9:54:59 AM UTC-8, Allen Cronce wrote:
Thanks. I just tried that (before seeing your email). It worked. The build
slave now has the correct env var value.
I guess that we can reboot as a work around. We don't change back and
forth between the trunk and branches that often.
But is there a more permanent solution? Maybe the problem you mentioned
has been fixed in an update?
On Friday, January 17, 2014 9:47:52 AM UTC-8, Jason Swager wrote:
Try restarting your slaves. There was an issue with EnvInject where
global variable changes wouldn't propagate to the slave unless the slave
was fully disconnected and reconnected.
On Friday, January 17, 2014 8:19:34 AM UTC-8, Allen Cronce wrote:
Hi all,
We've been trying to use Jenkins global env vars to define the svn URL
to use for some of our builds. While this seemed to work when we tested it
earlier, now that we're trying to set the env var back from a release
branch to the trunk, the value of the env var seems stuck for some build
jobs.
Our Machintosh full build has the old idea of the env var while our
Windows full build sees the new, correct env var value. Both of these jobs
are run on build slaves, not the Jenkins server. We're using Jenkins ver.
1.482.
Here's more details:
This is the env var is set in Configure System - Global properties -
Environment variables
name: FULL_BUILD_TRUNK_TO_USE
value: trunk
I've hacked our problematic Mac build job script to output what it
thinks is the value of this env var, then purposely error to stop the job.
I've also tried defining test env vars from the global one in the job
itself and via the env inject plugin as a test.
For the injected env var test, I've defined the following:
Build Environment - Inject environment variables to the build process
- Properties Content
INJECTED_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
For the build job env var test, I've defined the following:
Build Environment - Set environment variables
BUILD_ENV_VAR_TRUNK_TO_USE=$FULL_BUILD_TRUNK_TO_USE
Here's the hacked test build job script:
--snip--
#!/bin/sh
echo This is a hack to see what this build job thinks the build env var
is set to.
echo FULL_BUILD_TRUNK_TO_USE = ${FULL_BUILD_TRUNK_TO_USE}
echo INJECTED_TRUNK_TO_USE = ${INJECTED_TRUNK_TO_USE}
echo BUILD_ENV_VAR_TRUNK_TO_USE = ${BUILD_ENV_VAR_TRUNK_TO_USE}
exit 1
--snip--
In all cases, the above script code outputs the old branch value
of FULL_BUILD_TRUNK_TO_USE, not the new trunk value set in the global
config:
--snip--
[EnvInject] - Executing scripts and injecting environment variables
after the SCM step.
[EnvInject] - Injecting as environment variables the properties content
INJECTED_TRUNK_TO_USE=branches/RB-2.3.1
[EnvInject] - Variables injected successfully.
[ClientMacFull] $ /bin/sh
/var/folders/uu/uu50uc60HNO7gmdeMNxMEE+++TI/-Tmp-/hudson2189251323725654867.sh
This is a hack to see what this build job thinks the build env var is
set to.
FULL_BUILD_TRUNK_TO_USE = branches/RB-2.3.1
INJECTED_TRUNK_TO_USE = branches/RB-2.3.1
BUILD_ENV_VAR_TRUNK_TO_USE = branches/RB-2.3.1
--snip--
What's odd is that the Windows build does not have the same problem.
However one difference with that build is that the global env var is used
directly in the svn URL settings of that job, whereas the Mac build
manually calls svn directly from the script using the env var itself to
build the URL. So the Mac build script directly accesses the env var in the
script and the Windows build does not.
Any ideas as to what's wrong and how I can get this to work?
Thanks in advance for any suggestions.
Best,
Allen Cronce
--
You received this message because you are subscribed to the Google Groups
Jenkins Users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
