Re: Release 17 of the PostgreSQL Buildfarm Client

Lists: buildfarm-memberspgsql-hackers
From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "buildfarm-members(at)lists(dot)postgresql(dot)org" <buildfarm-members(at)lists(dot)postgresql(dot)org>
Subject: Release 17 of the PostgreSQL Buildfarm Client
Date: 2023-08-04 15:23:11
Message-ID: 6e00da65-f0dc-3fa7-8b06-49385e08d05c@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: buildfarm-members pgsql-hackers

I have pushed Release 17 of the PostgreSQL Buildfarm client.

Release 17 has two main features:

* Modernize the way we do cross-version upgrade tests. Most of the
logic for modifying instances to make them suitable for cross
version upgrade testing has now been migrated to the Postgres core
code in |src/test/perl/PostgreSQL/Test/AdjustUpgrade.pm|. The new
code simply imports this module and leverages its knowledge.
* Support of building with |meson|. This is only supported on version
16 or later of Postgres, older branches will continue to use the
older toolsets. To enable building with |meson|, there are several
new settings, illustrated in the sample configuration file:
o |using_meson| this must be set to a true value
o |meson_jobs| this controls the degree of parallelism that
|meson| will use
o |meson_test_timeout| this is used to multiply the meson test
timeout. The default is 3, 0 turns off timeout
o |meson_config| This is an array of settings for passing to
|meson setup|. Note that all options need to be explicitly given
here - the client disables all |auto| options. This includes use
of |zlib| and |readline|, which do not default to on, unlike
|autoconf| setups.

There are also a number of relatively small bug fixes and tweaks (e.g.
some improvements in processing typedefs).

The release is available at
<https://github.com/PGBuildFarm/client-code/releases> or
<https://buildfarm.postgresql.org/downloads/latest-client.tgz>

Enjoy!

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "buildfarm-members(at)lists(dot)postgresql(dot)org" <buildfarm-members(at)lists(dot)postgresql(dot)org>
Subject: Re: Release 17 of the PostgreSQL Buildfarm Client
Date: 2023-08-04 23:14:25
Message-ID: 3951994.1691190865@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: buildfarm-members pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I have pushed Release 17 of the PostgreSQL Buildfarm client.

I ran a test of this using

run_branches.pl --run-all --nosend --force

and noticed that it created "animal.force-one-run" files in each
of the per-branch directories, and never removed them. This
means (I assume) that the next run will also behave like --force
... and maybe all later ones too, until I manually remove those
files?

I'm not sure if this behavior is new in v17, or I just never
tried it before. I usually create force-one-run files manually.

regards, tom lane


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: "buildfarm-members(at)lists(dot)postgresql(dot)org" <buildfarm-members(at)lists(dot)postgresql(dot)org>
Subject: Re: Release 17 of the PostgreSQL Buildfarm Client
Date: 2023-08-05 01:25:16
Message-ID: 3973102.1691198716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: buildfarm-members pgsql-hackers

I wrote:
> I ran a test of this using
> run_branches.pl --run-all --nosend --force
> and noticed that it created "animal.force-one-run" files in each
> of the per-branch directories, and never removed them.

Further testing shows that a pre-existing force-one-run file does
get removed, so use-cases involving manual creation of the file
are still OK. Maybe this "force twice" from --force has been
there all along, and nobody noticed? Even if it's a new bug,
it's not a show-stopper.

regards, tom lane


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "buildfarm-members(at)lists(dot)postgresql(dot)org" <buildfarm-members(at)lists(dot)postgresql(dot)org>
Subject: Re: Release 17 of the PostgreSQL Buildfarm Client
Date: 2023-08-05 10:40:27
Message-ID: 793aa36e-e0a9-ca2e-c350-bac7054105cf@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: buildfarm-members pgsql-hackers


On 2023-08-04 Fr 21:25, Tom Lane wrote:
> I wrote:
>> I ran a test of this using
>> run_branches.pl --run-all --nosend --force
>> and noticed that it created "animal.force-one-run" files in each
>> of the per-branch directories, and never removed them.
> Further testing shows that a pre-existing force-one-run file does
> get removed, so use-cases involving manual creation of the file
> are still OK. Maybe this "force twice" from --force has been
> there all along, and nobody noticed? Even if it's a new bug,
> it's not a show-stopper.
>
>

This isn't a product of the --force flag. It's done so that --nosend and
--nostatus don't defeat the up-to-date checks in run_branches.pl by
writing a githead.log with a gitref we haven't reported on. We could
possibly do that another way, e.g. by removing or renaming the
githead.log file in such cases, since the checks in run_branches.pl rely
on that name. (thinks) In fact that's probably better, because instead
of forcing a run it would just make the code do a slow up-to-date check
(by doing a git pull) next time around. Will fix.

If you had used --test instead of --nosend this wouldn't have happened.

In any case, the next regular run (i.e. one without --nosend or
--nostatus) will remove the files.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com


From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "buildfarm-members(at)lists(dot)postgresql(dot)org" <buildfarm-members(at)lists(dot)postgresql(dot)org>
Subject: Re: Release 17 of the PostgreSQL Buildfarm Client
Date: 2023-08-05 11:50:36
Message-ID: a7d957e1-7a97-9b38-0480-f309d2a1978e@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: Postg토토 사이트 순위SQL pgsql-hackers


On 2023-08-05 Sa 06:40, Andrew Dunstan wrote:
>
>
> On 2023-08-04 Fr 21:25, Tom Lane wrote:
>> I wrote:
>>> I ran a test of this using
>>> run_branches.pl --run-all --nosend --force
>>> and noticed that it created "animal.force-one-run" files in each
>>> of the per-branch directories, and never removed them.
>> Further testing shows that a pre-existing force-one-run file does
>> get removed, so use-cases involving manual creation of the file
>> are still OK. Maybe this "force twice" from --force has been
>> there all along, and nobody noticed? Even if it's a new bug,
>> it's not a show-stopper.
>>
>>
>
>
> This isn't a product of the --force flag. It's done so that --nosend
> and --nostatus don't defeat the up-to-date checks in run_branches.pl
> by writing a githead.log with a gitref we haven't reported on. We
> could possibly do that another way, e.g. by removing or renaming the
> githead.log file in such cases, since the checks in run_branches.pl
> rely on that name. (thinks) In fact that's probably better, because
> instead of forcing a run it would just make the code do a slow
> up-to-date check (by doing a git pull) next time around. Will fix.
>
> If you had used --test instead of --nosend this wouldn't have happened.
>
> In any case, the next regular run (i.e. one without --nosend or
> --nostatus) will remove the files.
>

See
<https://github.com/PGBuildFarm/client-code/commit/ec4cf43613a74cb88f228efcde09931cf9fd57e7>

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com