I know that this is a resource constrained problem, but given the mountain of build errors we seem to be getting questions on the ML for, it strikes me that we should put more focus on getting the automated build farm up and running. Many of these issues could be identified, and hopefully resolved, prior to anyone actually encountering them.
Ruben, what is the status of the automated build system? Also, what is the status of other users being able to publish builds? This latter option, for those who don't know, allows other users to run their own automated build systems and then publish the results to the "primary" build server e.g. I have existing builds for Mac OS X, which will get published to the Kuleven server. This means that Ruben doesn't have to deal with that.
S
Automated builds
On Monday 13 December 2010 20:51:54 S Roderick wrote:
> I know that this is a resource constrained problem, but given the mountain
> of build errors we seem to be getting questions on the ML for, it strikes
> me that we should put more focus on getting the automated build farm up
> and running. Many of these issues could be identified, and hopefully
> resolved, prior to anyone actually encountering them.
>
> Ruben, what is the status of the automated build system?
The build.mech.kuleuven.be is back up and running. (I broke it when setting
the security stuff) This hudson build is meant to publish your own builds to.
For now everyone that has an account can publish builds to
build.mech.kuleuven.be. As long as this does not lead to any security
problems I'll keep it that way.
> Also, what is the
> status of other users being able to publish builds? This latter option,
> for those who don't know, allows other users to run their own automated
> build systems and then publish the results to the "primary" build server
> e.g. I have existing builds for Mac OS X, which will get published to the
> Kuleven server. This means that Ruben doesn't have to deal with that.
Secondly I would like to set up a complete matrix configuration of the Orocos
Toolchain and the other Orocos projects. But this will probably take me some
time to figure out and set up.
Ruben
> S
Automated builds
On Monday 13 December 2010 21:20:48 Ruben Smits wrote:
> On Monday 13 December 2010 20:51:54 S Roderick wrote:
> > I know that this is a resource constrained problem, but given the
> > mountain of build errors we seem to be getting questions on the ML for,
> > it strikes me that we should put more focus on getting the automated
> > build farm up and running. Many of these issues could be identified, and
> > hopefully resolved, prior to anyone actually encountering them.
> >
> > Ruben, what is the status of the automated build system?
>
> The build.mech.kuleuven.be is back up and running. (I broke it when setting
> the security stuff) This hudson build is meant to publish your own builds
> to. For now everyone that has an account can publish builds to
> build.mech.kuleuven.be. As long as this does not lead to any security
> problems I'll keep it that way.
>
> > Also, what is the
> > status of other users being able to publish builds? This latter option,
> > for those who don't know, allows other users to run their own automated
> > build systems and then publish the results to the "primary" build server
> > e.g. I have existing builds for Mac OS X, which will get published to the
> > Kuleven server. This means that Ruben doesn't have to deal with that.
>
> Secondly I would like to set up a complete matrix configuration of the
> Orocos Toolchain and the other Orocos projects. But this will probably
> take me some time to figure out and set up.
The most recent Hudson supports this quite well/easily. I'm running an
automatic matrix build with these axes: omniorb/tao, xenomai/gnulinux,
Debug/Release, i386/amd64.
I'm using git commit hooks to inform Hudson of new updates (instead of
polling) because polling is done on the slave, and the slave might not be
running.
When my slaves start up (master + virtual machines), the scheduled builds get
executed.
Peter
Automated builds
On 14/12/2010, at 21:54 , Peter Soetens wrote:
> On Monday 13 December 2010 21:20:48 Ruben Smits wrote:
>> On Monday 13 December 2010 20:51:54 S Roderick wrote:
>>> I know that this is a resource constrained problem, but given the
>>> mountain of build errors we seem to be getting questions on the ML for,
>>> it strikes me that we should put more focus on getting the automated
>>> build farm up and running. Many of these issues could be identified, and
>>> hopefully resolved, prior to anyone actually encountering them.
>>>
>>> Ruben, what is the status of the automated build system?
>>
>> The build.mech.kuleuven.be is back up and running. (I broke it when setting
>> the security stuff) This hudson build is meant to publish your own builds
>> to. For now everyone that has an account can publish builds to
>> build.mech.kuleuven.be. As long as this does not lead to any security
>> problems I'll keep it that way.
>>
>>> Also, what is the
>>> status of other users being able to publish builds? This latter option,
>>> for those who don't know, allows other users to run their own automated
>>> build systems and then publish the results to the "primary" build server
>>> e.g. I have existing builds for Mac OS X, which will get published to the
>>> Kuleven server. This means that Ruben doesn't have to deal with that.
>>
>> Secondly I would like to set up a complete matrix configuration of the
>> Orocos Toolchain and the other Orocos projects. But this will probably
>> take me some time to figure out and set up.
>
> The most recent Hudson supports this quite well/easily. I'm running an
> automatic matrix build with these axes: omniorb/tao, xenomai/gnulinux,
> Debug/Release, i386/amd64.
We do something similar, though it can take a while to sort out how to make the different matrixed jobs play nice together (ie KDL build picking up the RTT install, from the same matrix configuration).
> I'm using git commit hooks to inform Hudson of new updates (instead of
> polling) because polling is done on the slave, and the slave might not be
> running.
Ditto.
> When my slaves start up (master + virtual machines), the scheduled builds get
> executed.
What do you mean here?
We have a series of jobs (per branch) that build incrementally upon git commit. We also have a series of daily builds that are time triggered, which build from scratch. You pick up different issues with each. We also separated build/install, from running tests, and building docs, within a particular repository. So a repo typically has 3 jobs: build/install, run tests, and build docs. Saves time, continues dependent builds when tests fail, and builds the doc's no matter what happens with the build/test jobs.
We have dozens and dozens of jobs (we have over 10 separate repo's of OSS and proprietary code), and it took quite a bit of time to have them work together. Took much longer than I was happy with, but definitely worth it in the end.
YMMV
S