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

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 -->
                <exec executable="curl">
                        <arg line="-G" />
                        <arg value="" />
                        <arg line="-o ${buildDirectory}/nextBuildNumber" />
                <exec executable="bash" outputproperty="nextHudsonBuild">
                        <arg value="-c"/>
                        <arg value="grep -o 'nextBuildNumber&quot;:[0-9]*' ${buildDirectory}/nextBuildNumber | cut -d ':' -f 2"/>
                <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...


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.
> Steffen
> 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
>     weeks/month.
>     --
>     Dennis Hübner
>     Softwareentwickler
>     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 <
> --
> Steffen Pingel
> Senior Software Developer, Eclipse Mylyn
> Mylyn Tasks Lead
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx

cross-project-issues-dev mailing list

Back to the top