buildfarm vs code
От | Andrew Dunstan |
---|---|
Тема | buildfarm vs code |
Дата | |
Msg-id | 0f3d44a1-1ac5-599c-3e15-16d058d54e9a@2ndQuadrant.com обсуждение исходный текст |
Ответы |
Re: buildfarm vs code
Re: buildfarm vs code Re: buildfarm vs code |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: