From: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
---|---|
To: | Mikael Kjellström <mikael(dot)kjellstrom(at)mksoft(dot)nu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, buildfarm-members(at)postgresql(dot)org |
Subject: | Re: Reminder: spin up REL_11_STABLE on your buildfarm animals |
Date: | 2018-07-09 11:31:36 |
Message-ID: | 400d7809-1084-d9bf-61f1-bd66d29d3393@2ndQuadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | buildfarm-members |
On 07/09/2018 05:35 AM, Mikael Kjellström wrote:
>
> On 2018-07-08 17:52, Andrew Dunstan wrote:
>
>> If you're running the modern way via run_branches.pl with
>> branches_to_build set to ALL or HEAD_PLUS_LATESTn then this should
>> just happen without owner intervention when a new branch is created.
>> So I assume that all these are either running not using
>> run_branches.pl. or have hardcoded lists of branches in their config
>> files.
>
> Yes, I am using the run_build.pl on cron-schedule as I run most of the
> my animals on the same virtualized host and I need to control when
> different animal/branches builds so they don't overlap. If I would
> run run_branches.pl I have no control over how long each run will take
> and it's hard to schedule.
>
> But I've updated all my animals to include V11 now so they should all
> report in on the next run.
>
run_branches has a global lock that protects against concurrent runs of
different animals. You just point all the animals on the machine at the
same lock directory. I have several machines with this setup. See
global_lock_dir in the sample config file.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Mikael Kjellström | 2018-07-09 12:09:51 | Re: Reminder: spin up REL_11_STABLE on your buildfarm animals |
Previous Message | Mikael Kjellström | 2018-07-09 09:35:45 | Re: Reminder: spin up REL_11_STABLE on your buildfarm animals |