Re: Jenkins global env vars "stuck" for some slave jobs

[Jason Swager]

I believe that 
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.

Re: Jenkins global env vars "stuck" for some slave jobs

[Allen Cronce]

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

[Jason Swager]

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.

Jenkins global env vars "stuck" for some slave jobs

[Allen Cronce]

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.