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.
