Subject: Release 17 of the PostgreSQL Buildfarm Client

From: Andrew Dunstan <[email-masked]>
Date: Fri, 4 Aug 2023 11:23:11 -0400

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 <[email-masked]>
Date: Fri, 04 Aug 2023 19:14:25 -0400

> 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 <[email-masked]>
Date: Fri, 04 Aug 2023 21:25:16 -0400

I wrote:
> 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 <[email-masked]>
Date: Sat, 5 Aug 2023 06:40:27 -0400

> there all along, and nobody noticed?  Even if it's a new bug,

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

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 5 Aug 2023 07:50:36 -0400

On 2023-08-05 Sa 06:40, Andrew Dunstan wrote:
> 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.
>

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

cheers

andrew