I believe that
JENKINS-14623<https://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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
