Обсуждение: buildfarm vs code
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
Вложения
On 06/05/2018 12:09 PM, Andrew Dunstan wrote: > > 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. Of course that's lines 36 and 43. I seem to be getting more dyslectic as I get older ... cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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. 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 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 > 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. -- Thomas Munro http://www.enterprisedb.com
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
On Wed, Jun 6, 2018 at 9:05 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
It happens during startup, see CreateRestrictedProcess in src/bin/pg_ctl/pg_ctl.c.
-- 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.
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
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
> 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?
On 06/06/2018 09:16 AM, Amit Kapila wrote: > > > 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? > > > It happens during startup, see CreateRestrictedProcess in > src/bin/pg_ctl/pg_ctl.c. > > Yeah, what seems quite odd, though, is that when run as an unprivileged use the tablespace test runs just fine, but when run as a privileged user it fails. If that's fixable we should fix it :-) cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> Yeah, what seems quite odd, though, is that when run as an unprivileged
> use the tablespace test runs just fine, but when run as a privileged
> user it fails. If that's fixable we should fix it :-)
I'm curious to know what the failure looks like exactly?
regards, tom lane
On 06/06/2018 10:24 AM, Tom Lane wrote: > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >> Yeah, what seems quite odd, though, is that when run as an unprivileged >> use the tablespace test runs just fine, but when run as a privileged >> user it fails. If that's fixable we should fix it :-) > I'm curious to know what the failure looks like exactly? > > [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace ERROR: could not set permissions on directory "C:/projects/pg-devel/src/test/regress/testtablespace": Permission denied [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:8] pg_regress/tablespace STATEMENT: CREATE TABLESPACE regress_tblspace LOCATION 'C:/projects/pg-devel/src/test/regress/testtablespace'; See https://ci.appveyor.com/api/buildjobs/ro18n2w04vr18hlx/log cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 06/06/2018 10:24 AM, Tom Lane wrote:
>> I'm curious to know what the failure looks like exactly?
> [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace
> ERROR: could not set permissions on directory
> "C:/projects/pg-devel/src/test/regress/testtablespace": Permission denied
> [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:8] pg_regress/tablespace
> STATEMENT: CREATE TABLESPACE regress_tblspace LOCATION
> 'C:/projects/pg-devel/src/test/regress/testtablespace';
Hmph. So, looking at tablespace.c, what we're seeing is chmod() returning
EACCES. AFAICT from googling, Microsoft do provide chmod() directly, it's
not some emulation of ours ... but they don't document that an EACCES
failure is even possible, let alone what the triggering conditions are.
Sigh.
Perhaps it'd be useful for investigation purposes to replace the chmod()
with whatever the native Windows equivalent is, and see just which
Microsoft error code it returns.
regards, tom lane
On 06/06/2018 01:52 PM, Tom Lane wrote: > Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes: >> On 06/06/2018 10:24 AM, Tom Lane wrote: >>> I'm curious to know what the failure looks like exactly? >> [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:7] pg_regress/tablespace >> ERROR: could not set permissions on directory >> "C:/projects/pg-devel/src/test/regress/testtablespace": Permission denied >> [00:07:37] 2018-06-06 17:25:41.662 UTC [1904:8] pg_regress/tablespace >> STATEMENT: CREATE TABLESPACE regress_tblspace LOCATION >> 'C:/projects/pg-devel/src/test/regress/testtablespace'; > Hmph. So, looking at tablespace.c, what we're seeing is chmod() returning > EACCES. AFAICT from googling, Microsoft do provide chmod() directly, it's > not some emulation of ours ... but they don't document that an EACCES > failure is even possible, let alone what the triggering conditions are. > Sigh. > > Perhaps it'd be useful for investigation purposes to replace the chmod() > with whatever the native Windows equivalent is, and see just which > Microsoft error code it returns. > > Maybe this should be SetSecurityInfo(). cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 05.06.18 18:09, Andrew Dunstan wrote: > 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. This seems reasonable. I wonder if this could also be used in a way that allows minimally validating the msvc build configuration on a different platform, e.g., if adding or removing a file. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 02/07/18 10:57, Peter Eisentraut wrote: > On 05.06.18 18:09, Andrew Dunstan wrote: >> 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. > > This seems reasonable. There's already a separate script for this, src/tools/msvc/mkvcbuild.pl. Doesn't that do the same thing? - Heikki
On 07/12/2018 05:54 AM, Heikki Linnakangas wrote: > On 02/07/18 10:57, Peter Eisentraut wrote: >> On 05.06.18 18:09, Andrew Dunstan wrote: >>> 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. >> >> This seems reasonable. > > There's already a separate script for this, > src/tools/msvc/mkvcbuild.pl. Doesn't that do the same thing? > > Yes, it does, more or less. For some reason I'd completely forgotten about it. I'll withdraw the patch. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services