buildfarm vs code - Mailing list pgsql-hackers

From Andrew Dunstan
Subject buildfarm vs code
Date
Msg-id 0f3d44a1-1ac5-599c-3e15-16d058d54e9a@2ndQuadrant.com
Whole thread Raw
Responses Re: buildfarm vs code
Re: buildfarm vs code
Re: buildfarm vs code
List pgsql-hackers
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]

However, it has made two adjustments to the perl source, which is rather 
against the philosophy of the buildfarm. The buildfarm client does not 
ever make any adjustments or patches to postgres code, and in normal 
reporting operation refuses to run if it detects any such changes. 
However, notice at lines 36 and 34 or the Appveyor output, (from lines 
16 and 19 of the recipe appveyor.yml) that this recipe does make a 
couple of adjustments.

The first should be simple and non-controversial. It allows 
src/tools/msvc/build.pl to be called in such a way that it only creates 
the project files and then stops. This is a one line addition to the 
script and should affect nobody not using the option. A patch for it is 
attached.

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. 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.")


cheers


andrew


[1] http://www.pgcon.org/2018/schedule/events/1183.en.html

[2] https://github.com/PGBuildFarm/appveyor-build

[3] https://ci.appveyor.com/project/AndrewDunstan/pgdevel-6sfth/build/1.0.40

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: "MauMau"
Date:
Subject: Re: I'd like to discuss scaleout at PGCon