Re: buildfarm vs code

From: Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: buildfarm vs code
Date: 2018-06-06 12:47:06
Message-ID: 622178e5-028f-b4c9-2d2d-d8442dc9ffde@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/05/2018 11:35 PM, Thomas Munro wrote:
> On Wed, Jun 6, 2018 at 4:09 AM, Andrew Dunstan
> <andrew(dot)dunstan(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-06-06 12:59:43 Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?
Previous Message Ashutosh Bapat 2018-06-06 11:51:06 Re: Remove mention in docs that foreign keys on partitioned tables are not supported