Re: buildfarm vs code

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: buildfarm vs code
Дата
Msg-id 622178e5-028f-b4c9-2d2d-d8442dc9ffde@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: buildfarm vs code  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Remove mention in docs that foreign keys on partitioned tablesare not supported
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Why is fncollation in FunctionCallInfoData rather than fmgr_info?