Hello Eike,

I had the exact same problem in the Orion build which got broken by this 
change. We were using nextBuildNumber to interact with a hudson job 
remotely from another script on build.eclipse.org. After some digging I 
found there is a Hudson JSON API that allows you to get that information 
remotely:

https://hudson.eclipse.org/hudson/job/emf-cdo-integration/api/json

There is probably an easier way to process this that I overlooked, but I 
used some simple bash commands to process the result and extract the build 
number. In case it helps, here is the complete script I ended up with:

                <!-- fetch the next hudson build number from the hudson 
job API -->
                <exec executable="curl">
                        <arg line="-G" />
                        <arg value="
https://hudson.eclipse.org/hudson/job/orion-jstest-windows/api/json"; />
                        <arg line="-o ${buildDirectory}/nextBuildNumber" 
/>
                </exec>
                <exec executable="bash" outputproperty="nextHudsonBuild">
                        <arg value="-c"/>
                        <arg value="grep -o 'nextBuildNumber&quot;:[0-9]*' 
${buildDirectory}/nextBuildNumber | cut -d ':' -f 2"/>
                </exec>
                <echo message="Next hudson build number is 
${nextHudsonBuild}."/>

Even if the next build number isn't the only shared data you're looking 
for, a similiar approach might work for you...

John





Eike Stepper <step...@esc-net.de> 
Sent by: cross-project-issues-dev-boun...@eclipse.org
12/11/2011 03:37 AM
Please respond to
Cross project issues <cross-project-issues-dev@eclipse.org>


To
cross-project-issues-dev@eclipse.org
cc

Subject
Re: [cross-project-issues-dev] Hudson change






Hi,

The CDO promotion system (that I've invested more than 3 weeks of full 
time work into) also stopped working because it 
relies on accessing (reading) various shared files such as 
/shared/jobs/emf-cdo-integration/nextBuildNumber. I couldn't 
find a solution to this problem in this thread. Is there any?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



Am 07.12.2011 16:27, schrieb Steffen Pingel:
> As a middle ground, you can grant Hudson write access to a staging 
location and then promote artifacts from there to
> your actual download location with more restrictive permissions 
(manually or using a cron on build.eclipse.org
> <http://build.eclipse.org>).
>
> In the end we all need to trust Hudson anyways to the extend that the 
produced binaries aren't tainted. Keeping
> artifacts in the Hudson workspace won't protect them any better than 
storing them in a different location that's
> more convenient to access. Both locations will inherently writeable by 
all other Hudson jobs.
>
> Steffen
>
>
> P.S.: Some directory names on download.eclipse.org <
http://download.eclipse.org> are excluded from mirroring (such as
> archive/ I believe).
>
>
> On Wed, Dec 7, 2011 at 4:00 PM, Dennis Hübner <dennis.hueb...@itemis.de 
<mailto:dennis.hueb...@itemis.de>> wrote:
>
>     Am 07.12.11 15:44, schrieb Webmaster(Matt Ward):
>     >  3) You can use the http/s links to get the files and put them 
where
>     >  your releng scripts expect, then run your release tools.  After 
that
>     >  you can work on updating your tools.
>     ... and then? Wait for the next "potential fix"?
>     Now I understand release engineers who just grand hudson (or even 
all)
>     write access to their project download locations, to finally get the
>     whole release/promote process working for more then just a couple of
>     weeks/month.
>
>     --
>     Dennis Hübner
>
>     Softwareentwickler
>
>     Mobil:   0151 173 96 707
>
>     http://www.itemis.de/
>
>     itemis AG
>     Am Germaniahafen 1
>     24143 Kiel
>
>     Rechtlicher Hinweis:
>     Amtsgericht Dortmund, HRB 20621
>     Vorstand: Wolfgang Neuhaus, Jens Wagener, Dr. Georg Pietrek
>     Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.), Stephan Grollmann, 
Michael Neuhaus
>
>     _______________________________________________
>     cross-project-issues-dev mailing list
>     cross-project-issues-dev@eclipse.org <
mailto:cross-project-issues-dev@eclipse.org>
>     https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
>
> --
> Steffen Pingel
> Senior Software Developer, Eclipse Mylyn
> Mylyn Tasks Lead
> http://tasktop.com
>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to