Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Hudson change

Hi John,

Thank you for the hint! Unfortunately there's indeed much more in our promotion service that relies on filesystem access.

Webmasters, wouldn't it be possible to make the jobs/ area, which is now local to the master, somehow readable from



Am 12.12.2011 03:09, schrieb John Arthorne:
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 After some digging I found there is a
Hudson JSON API that allows you to get that information remotely:

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 -->
<argline="-o ${buildDirectory}/nextBuildNumber"/>
<argvalue="grep -o 'nextBuildNumber&quot;:[0-9]*' ${buildDirectory}/nextBuildNumber | cut -d ':' -f 2"/>
<echomessage="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...


*Eike Stepper <stepper@xxxxxxxxxx>*
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

12/11/2011 03:37 AM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

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



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?


---- <> <>

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
 < <>>).

 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.


 P.S.: Some directory names on < <>> are
excluded from mirroring (such as
 archive/ I believe).

 On Wed, Dec 7, 2011 at 4:00 PM, Dennis Hübner <dennis.huebner@xxxxxxxxx <mailto:dennis.huebner@xxxxxxxxx>> 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

 Dennis Hübner


 Mobil: 0151 173 96 707

 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@xxxxxxxxxxx <mailto:cross-project-issues-dev@xxxxxxxxxxx>

 Steffen Pingel
 Senior Software Developer, Eclipse Mylyn
 Mylyn Tasks Lead <>

 cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Back to the top