From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Rémi Zara <remi_zara(at)mac(dot)com> |
Cc: | pgbuildfarm-members(at)pgfoundry(dot)org |
Subject: | Re: [Pgbuildfarm-members] Specifying multiple branches to try |
Date: | 2010-09-26 12:26:16 |
Message-ID: | 4C9F3BE8.2020200@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | buildfarm-members |
I'm still thinking about this a bit. As it is I don't think it will
work, because the config file expects that the branch is known at the
time it is included, so we can't change the branch after that point. I'm
playing around with the idea of a wrapper script that would either try
to hold an election somewhat like your scheme below, but in such a way
as to avoid possible starvation, or would try to run all the given
branches - something I did on quoll but rather informally.
I like the idea of a global lock - I think that's possibly worth doing
on its own.
cheers
andrew
On 09/24/2010 01:10 PM, Rémi Zara wrote:
> Hi,
>
> My buildfarm member is quite slow (6h30 at least per run), and has limited resources which makes building more than one branch at the same time impractical. Scheduling the runs so that they do not overlap is not ideal/easy.
> So here is a patch that allows to specify multiple branches to try on the command line ("run_build.pl REL8_4_STABLE REL9_0_STABLE HEAD"). When this is the case:
> * a global lock is set in the buildroot to prevent other run to overlap
> * each branch is tested in order to see if there is something to build
> * the first which has something to build "wins"
>
> All is otherwise unchanged, and code is mostly moved around to accommodate the loop.
>
> Do you think something like this might be integrated ?
>
>
>
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2010-09-27 12:13:07 | Git migration deadline for Buildfarm |
Previous Message | Aidan Van Dyk | 2010-09-23 17:18:45 | Re: Git cvsserver serious issue |