[Buildbot-devel] Daily builds

[Nick Trout]

> Just set 'periodicBuildTime'=SECS in the dictionary that goes into
> c['builders']. So to make your 'docs' builder run once a day, turn
this:

Ah great. I'll try that.

> (incidentally, the Scheduler work makes this a lot cleaner: there is a
> scheduler.Periodic class that fires in the same way as
periodicBuildTime
> behaves, and it would be little work to write a class that fires the
build
> at
> specific times of day. Having a Builder not run in response to Changes
is
> as
> simple as not hooking up the usual Change-based Scheduler to that
> Builder.)

This new scheduler sounds interesting. I don't think we're really using
BB how it was intended, i.e. one target per slave with incremental steps
to create an end target. I just do a P4 sync (not in the workdir) and
then build whichever targets I want by issuing steps (through batch
files). I've set it up so one slave make multiple targets sequentially
because I don't want them building at the same time (the performance of
the builds is worse than twice the time, what with VM paging and I/O
bottlenecks), and the waterfall can get quite cluttered. I could run 2
slaves with an interlock but I have combining steps at the end where I
want to commit multiple targets at the same time so it seems more
logical to do it on one slave. I'm kind of experimenting at the moment
so I might try the multiple slaves approach again.

Reading Michaels and a couple of other mails again it sounds like there
is possible need for more flexible conditional stepping system. Perhaps
you could do something like create a "status" object when a build is
created and then this is passed to each of the steps (perhaps a pickled
object is passed around?). This way the step could look back through the
history to see what the results of previous operations were. Other
features that might be nice would be the ability to email different
people depending on the step that failed. It would also be nice if the
status object contained the changes that sparked this build - as you
might look at paths or comments that were made for hints what went
wrong. 

If you did put in support for passing objects around like this slaves
might dump out "reports" which could be linked to from the steps. E.g. a
step might produce some stats in HTML and then post this back to the
master. The master could then cache this with the logs and link it into
the waterfall. The logs would still be used to track the build process,
but the reports would give more palatable information about what is
going on.

Nick