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":[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
