Re: Buildfarm "master-next" branch?

On 04/17/2014 09:17 AM, Robert Haas wrote:

> In terms of improving the buildfarm infrastructure, the thing I would
> most like to have is more frequent runs. It would be great if pushing
> a commit to the master repository triggered an immediate build on
> every buildfarm animal so that you could see all of the failures in a
> short period of time. But that would require more resources for the
> buildfarm machines, which are provided on a strictly volunteer basis,
> so it's hard to see how to arrange that.

Some buildfarm owners run at pretty high frequency - I know there are
cron jobs on some running every 15 minutes. My own Linux and FBSD
machines run every hour. Windows builds take longer - depending on other
use of resources they can run a couple of hours per branch. Also my two
Windows machines doing buildfarm work are running a total of 5 animals,
so the runs are staggered - on Windows 8 the two animals each run every
3 hours. Note that each run potentially builds all the branches, if
there has been some backported change, and the windows animals are set
up so that if animal A on the same machine is running when animal B's
run time comes around animal B skips it scheduled run. So sometimes you
do have to wait a bit. If someone were to providfe me with a bunch of
nice fast Windows VMs I would set them up with one animal a piece with
frequent runs and we might get a lot better coverage. But I am tapped
out as far as the resources I can provide go.

>
> But the ability to easily spin up temporary branches for testing would
> also be great. Unfortunately, I suspect that only a minority of the
> buildfarm owners would choose to participate, which would make it less
> useful, but if we could solve that problem I'd be all in favor of it.
> I'm not volunteering to do the work, though.

The buildfarm's original purpose was to give early warning of
platform-specific problems of code we had *already* decided on. Now
projects morph, so we might decide to do something like this. But we'd
need to think long and hard about it. Postgres has not historically used
short-lived branches. I don't much like Craig's idea of a long-lived
testing branch that we're going to do commits and reverts on. If we're
going to do something like this it would be much better to make some
provision for short-lived topic branches. e.g. say we allowed branches
with names like testme-platformname-featurename, (platformname here
could be a magic "all", or a comma-separated list of names such as
linux, freebsd, windows). Wnen testing is done, we could merge the
branch if the testing worked out OK, or drop it if the testing proved to
be a failure.

There would be some work to make the buildfarm client suitable for this.
And we'd probably need a "testing dashboard" so as to keep the main
dashboard page free of test branch results.

Of course, all this would be done in my copious spare time *cough*. I'm
not sure this would be the best use of it.

cheers

andrew