latest buildfarm client release
I have just released version 4.16 of the PostgreSQL Buildfarm client
It can be downloaded from
<http://www.pgbuildfarm.org/downloads/latest-client.tgz>
Several bugs have been fixed, and there are these non-trivial changes:
* capturing of TAP test logs
* bin check enabled on Windows
* rm_worktrees feature
* an experimental module to run Sepgsql tests
* try database shutdown following a start failure
* report all PGBuild module versions to server
rm_worktrees is enabled by putting this in your config file:
rm_worktrees => 1,
The effect is that at the end of a run the checked out work tree is
removed, leaving just the git repository, which in turn might be mostly
linked to your HEAD branch if you use the git_use_workdirs option.
Before a run, the work tree will be checked out again. The net effect is
a significant saving in space used. with these two options, the
additional space for each branch except when it's actually building is
reduced to less than 30Mb. On crake, the git mirror, branch trees and
cache now come in at about 1.5Gb. That's a lot less than it used to be.
Shutdown after a start failure tries to remedy a situation where we try
to start the server, and don't detect that it has started, but it has in
fact started. So now if we get a failure we try to shut down any server
that might have started, just in case. This change is possibly redundant
given the recent change where postgres detects that its data directory
has disappeared and shuts down when it has, but it's probably worth
having anyway.
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
On Sun, Nov 22, 2015 at 2:29 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
I have just released version 4.16 of the PostgreSQL Buildfarm client
It can be downloaded from <
http://www.pgbuildfarm.org/downloads/latest-client.tgz>Several bugs have been fixed, and there are these non-trivial changes:
* capturing of TAP test logs
* bin check enabled on Windows
* rm_worktrees feature
* an experimental module to run Sepgsql tests
* try database shutdown following a start failure
* report all PGBuild module versions to server
Thanks Andrew!
--
Michael
Andrew Dunstan <andrew@dunslane.net> writes:
I have just released version 4.16 of the PostgreSQL Buildfarm client
I updated my critters to 4.16, and since nothing much was happening in
git, decided to test by doing "run_build.pl --nosend --verbose --force"
manually on prairiedog. That run went fine, but the cron job firing
run_branches.pl every few minutes was still live, and one of its runs
went a tad nuts even though nothing was happening in git:
Buildfarm member prairiedog failed on REL9_3_STABLE stage pgsql-Git
Buildfarm member prairiedog failed on REL9_4_STABLE stage pgsql-Git
Buildfarm member prairiedog failed on REL9_5_STABLE stage pgsql-Git
That resulted in these reports uploaded to the server:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A27%3A29
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A27%3A19
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A26%3A12
which contain the following failure reports, respectively:
Missing checked out branch bf_REL9_5_STABLE:
fatal: Not a git repository (or any of the parent directories): .git
Missing checked out branch bf_REL9_4_STABLE:
fatal: Not a git repository (or any of the parent directories): .git
fatal: unable to read tree 719b1b413b507d0fc86162f6aa45b6e44e6d82a1
Cannot rebase: Your index contains uncommitted changes.
Please commit or stash them.
None of that makes any possible sense, because I certainly wasn't touching
the git tree by hand, and the run_build job was only touching HEAD.
There's nothing really broken on the machine, because the next set of
runs went through fine.
Don't know what to make of this, except that probably the buildfarm
script's concurrent-job interlocks need some attention.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 11/22/2015 12:47 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
I have just released version 4.16 of the PostgreSQL Buildfarm client
I updated my critters to 4.16, and since nothing much was happening in
git, decided to test by doing "run_build.pl --nosend --verbose --force"
manually on prairiedog. That run went fine, but the cron job firing
run_branches.pl every few minutes was still live, and one of its runs
went a tad nuts even though nothing was happening in git:Buildfarm member prairiedog failed on REL9_3_STABLE stage pgsql-Git
Buildfarm member prairiedog failed on REL9_4_STABLE stage pgsql-Git
Buildfarm member prairiedog failed on REL9_5_STABLE stage pgsql-GitThat resulted in these reports uploaded to the server:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A27%3A29
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A27%3A19
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2015-11-21%2018%3A26%3A12which contain the following failure reports, respectively:
Missing checked out branch bf_REL9_5_STABLE:
fatal: Not a git repository (or any of the parent directories): .gitMissing checked out branch bf_REL9_4_STABLE:
fatal: Not a git repository (or any of the parent directories): .gitfatal: unable to read tree 719b1b413b507d0fc86162f6aa45b6e44e6d82a1
Cannot rebase: Your index contains uncommitted changes.
Please commit or stash them.None of that makes any possible sense, because I certainly wasn't touching
the git tree by hand, and the run_build job was only touching HEAD.
There's nothing really broken on the machine, because the next set of
runs went through fine.Don't know what to make of this, except that probably the buildfarm
script's concurrent-job interlocks need some attention.
Oh, ouch. Well, that message comes from us just doing "git branch" to
sanity check what branch we're on, and that happens before anything that
was changed in this release. I had assumed, possibly naively, that git
would lock against itself. Maybe not with multiple workdirs. This only
matters if you're using git_use_workdirs, like you are, since otherwise
the git repos are totally independent, and run_build is definitely
locked against itself on a given branch. I'll look at adding a global
wait lock, just while git checkout is running, to cover this case. In
normal operation we don't expect this to occur, since run_branches.pl
just runs branches one at a time, so I don't think we need to put out an
emergency fix, but you've uncovered a corner case that all my testing
has missed.
Thanks for the report.
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