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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
