Release 17 of the PostgreSQL Buildfarm Client
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
Andrew Dunstan <andrew@dunslane.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
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
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
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