It might also depends on the caching added lately to prevent reading too much 
unnecessary information into memory.

Note that I'm not in front of my computer so what I'm saying in this mail and 
the last one are somewhat speculations, but some hints on where to look at now 
to see if you can solve this.

R.

On 2013-01-22, at 17:39, J Arrizza <cppge...@gmail.com> wrote:

> Update:
> 
> I tried a quick change: 
>   - find the scm node and 
>   - insert the assignedNode element after it. 
> 
> Still no joy.
> 
> The only thing left that I can see, is there is a missing "\n" after the 
> </assignedNode> when my script inserts the new node:
> 
>   <assignedNode>tm9</assignedNode><actions/>
> 
> while Jenkins adds the newline:
> 
>   <assignedNode>tm9</assignedNode>
>   <actions/>
> 
> That would imply something very wrong with the XML parser in Jenkins, so it 
> seems very unlikely this is the problem... but I thought I'd ask it anyway.
> 
> John
> 
> On Tue, Jan 22, 2013 at 1:56 PM, J Arrizza <cppge...@gmail.com> wrote:
>> Hi,
>> 
>> I'm writing some scripts to keep track of and update the nodes my jobs use. 
>> I've come across a problem that I can't seem to resolve. This is a rather 
>> long post, but I want to make sure I give you the info you need.
>> 
>> If the "Restrict where this project can be run" is checked on the web page, 
>> a node appears in the config.xml:
>> 
>>   <scm class="hudson.plugins.mercurial.MercurialSCM" plugin="mercurial@1.41">
>>     <source>http://cm5/hg/sandbox/v01.0/int</source>
>>     <modules/>
>>     <clean>false</clean>
>>     <browser class="hudson.plugins.mercurial.browser.HgWeb">
>>       <url>http://cm5/hg/sandbox/v01.0/int/</url>
>>     </browser>
>>   </scm>
>>   <assignedNode>master</assignedNode>
>>   <canRoam>false</canRoam>
>> 
>> You can see "assignedNode" sandwiched between the scm and canRoam elements. 
>> When you uncheck "Restrict where this project can be run", the element 
>> disappears from config.xml. 
>> 
>> So far, so good.
>> 
>> I created a ruby script that gets the xml via the api/config.xml interface. 
>> It looks for that node and if it's not found, it adds it (BTW I use 
>> nokogiri). But my testing is showing that even if I add the node, the 
>> checkbox in the web page doesn't get checked.
>> 
>> Here are some notes:
>> - If I check the box on the web page and my script just changes the value in 
>> it (e.g. from 'master' to 'tm9' and back again), it works perfectly. I run 
>> the script, I refresh the web page, and the new value shows up. 
>> 
>> - When the script adds assignedNode, it adds it to the end of the xml root 
>> element, but no joy:
>> 
>>   <buildWrappers/>
>> <assignedNode>tm9</assignedNode></project>
>> 
>> - I tried adding to the front of the xml root element, with no joy:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <project>
>>   <assignedNode>tm9</assignedNode><actions/>
>>   <description>desc</description>
>> 
>> - When I add the assignedNode, it is actually in the config.xml. After I add 
>> it,  update the job via the api/xml, and then do a retrieve using api/xml, 
>> the config.xml has the node in it. So Jenkins isn't erasing it or anything 
>> like that.
>> 
>> - If my node is in the config.xml and I check the box on the web page, it 
>> moves to just under the scm node and it all works correctly again.
>> 
>> - I have done this for several other nodes, checkboxes, etc. and they are 
>> working correctly. 
>> 
>> - I have done this extensively for Hudson and it's working correctly too. 
>> Note that the assignedNode in Hudson is called appointedNode and has a few 
>> extra fields in there.
>> 
>> So, finally, my question: is the assignedNode element position dependent in 
>> the config.xml?
>> 
>> John
> 

Reply via email to