Re: buildfarm vs code - Mailing list pgsql-hackers
From | Andrew Dunstan |
---|---|
Subject | Re: buildfarm vs code |
Date | |
Msg-id | 622178e5-028f-b4c9-2d2d-d8442dc9ffde@2ndQuadrant.com Whole thread Raw |
In response to | Re: buildfarm vs code (Thomas Munro <thomas.munro@enterprisedb.com>) |
List | pgsql-hackers |
On 06/05/2018 11:35 PM, Thomas Munro wrote: > On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan > <andrew.dunstan@2ndquadrant.com> wrote: >> At my talk at pgcon last Friday [1] I presented some ideas for how people >> could run a full buildfarm run against their code, including a 4 line recipe >> using some Docker recipes I had created. Thomas Munro suggested it would be >> even nicer if you could just point something like Appveypr at the code and >> have it do the buildfarm run. That intrigued me a bit, so I created a recipe >> for that. Along the way there are a few adjustments to how the buildfarm >> client runs, which is why the recipe [2] runs with a git clone rather than a >> published release. Nevertheless it does seem to work [3] > Very nice! Thank you for working on this. So it seems like we're > pretty close to being able to use the standard buildfarm software to > manage automatic Windows testing of PostgreSQL from any personal git > repo, and also for cfbot's testing of CF submissions. > > Would this dump the build log to stderr if it fails, so you could see > it on appveyor? I'd also like to see compiler warnings (and perhaps > enable the equivalent of -Werror). How should we access that -- is > there a just-write-everything-to-stdout mode? It suppose we could > just add some scripting to find and dump all log files. Any make errors should be echoed, as I understand it, even in quiet mode. Otherwise, possibly I need to experiment with a custom build script. One of the adjustments I made to the buildfarm client is to add a --show-error-log option which echoes the log of any failing stage. > > The quick-and-dirty configuration I've been using for cfbot also runs > a bit of perl on failure to locate and dump out any regression.diffs > files, like this: > > https://ci.appveyor.com/project/postgresql-cfbot/postgresql/build/1.0.1127 > https://github.com/macdice/cfbot/blob/master/appveyor/appveyor.yml#L22 > https://github.com/macdice/cfbot/blob/master/appveyor/dumpregr.pl The buildfarm client already knows how to do this. In fact it dumps rather more than just regression.diffs. e.g. it dumps the postmaster log. With --show-error-log it will output that on the console for a failing stage. > > I wonder if it's possible to teach it to locate and backtrace any core > files, as cfbot does on Linux: > > https://github.com/macdice/cfbot/blob/master/travis/.travis.yml#L28 I've had at best indifferent success in getting backtraces on Windows >> The second change the recipe makes is to disable the tablespace tests. On >> Windows, when running as the Administrator, the application gives up >> privilege to such an extent that the tablespace tests fail. > Ohh. I was confused about why Windows was giving us fewer privileges > when we had a more privileged account, but in fact *we* did that. > Where does the privilege-giving-up happen? > >> The answer is >> usually to run as a non-Admin user, and this is what I do for animals like >> jacana and bowerbird. However, setting that up so that it hooks up nicely to >> the appveyor console is ugly and fragile. So I'd like either to solve this >> issue (perhaps be more discriminating about what privileges we give up) or >> provide a builtin way to skip these tests. In the latter case, maybe a >> skip-tests setting for pg_regress would work well. I can imagine other uses >> for it ("I know I'm going to break this test but I want to run all the >> others.") > I really want this to actually work rather than being skipped, because > I'm working on stuff related to tablespaces and I want CI for that on > Windows. > > If we fixed those things it seems we'd almost have an .appveyor.yml > good enough to start talking about putting it in our source tree, to > provide a solid default for anyone working on PostgreSQL. > Sure. Let's solve that if we can. It's more than annoying. This Windows Restricted Token stuff is a black box to me. Maybe we need to start a separate thread for that discussion. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
pgsql-hackers by date: