On 05/10/2012 06:49 AM, Magnus Hagander wrote:
> On Thu, May 10, 2012 at 12:43 PM, Andrew Dunstan<andrew@dunslane.net> wrote:
>>
>> On 05/10/2012 01:29 AM, Tom Lane wrote:
>>> Bruce Momjian<bruce@momjian.us> writes:
>>>> The docs finally built 90 minutes after my commit, and the URL above is
>>>> now working. (Does it always take this long to update?)
>>> I believe the new implementation of that stuff is that the devel docs
>>> are built whenever the buildfarm member guaibasaurus runs for HEAD,
>>> which it seems to do on an hourly schedule. This is definitely not as
>>> fast-responding as Peter's former custom script, but I'm not sure if
>>> it's worth thinking of another way.
>>>
>> I don't see any reason it can't run more frequently, though. Currently a run
>> takes 15 minutes or so. We could reduce that by making it skip some steps,
>> and get it down to about 10 minutes. It would be perfectly reasonable to run
>> every 5 minutes (it won't schedule concurrent runs - if the lock file is
>> held by another run it exits gracefully). Of course, that's up to Magnus and
>> Stefan.
> If we can make it do *just* the docs, we can certainly run it a bit
> more often. But we don't want to make it run the full set of checks
> more or less continously, since the machine is shared with a number of
> other tasks...
>
> I don't think 5 minutes is anywhere near necessary even for the docs,
> but there is a lot of room between 5 minutes and 4 hours, so we can
> definitely shorten it.
>
If you only want a docs build then a buildfarm animal is probably not a
good choice. Do you want to divorce that from building validated snapshots?
BTW, if there has been no change a buildfarm animal normally does no
work (other than a git pull followed by the check for updates), which is
why it's often safe to schedule it very frequently. However, if you need
to schedule tasks at times when it's known not to be running then a
sparse schedule makes sense.
cheers
andrew