Re: Buildfarm "master-next" branch? - Mailing list pgsql-hackers

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