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

To
cross-project-issues-dev@xxxxxxxxxxx
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.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
>
>    
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@xxxxxxxxxxx <
mailto:cross-project-issues-dev@xxxxxxxxxxx>
>    
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@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

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



Back to the top