Horton
Menu

Re: CI and test improvements

Thomas Munro <thomas.munro@gmail.com>

View thread
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, Andres Freund <andres@anarazel.de>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org, Noah Misch <noah@leadboat.com>, Michael Paquier <michael@paquier.xyz>, Anastasia Lubennikova <lubennikovaav@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Daniel Gustafsson <daniel@yesql.se>, samay sharma <smilingsamay@gmail.com>
Date: 2023-02-03T01:58:04Z
Lists: pgsql-hackers 
On Thu, Feb 2, 2023 at 2:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > Some observations:
> > So what should our policy be on when to roll the CI image forward?  I
> > guess around New Year/now (~6 months after release) is a good time and
> > we should just do it.  Anyone got a reason why we should wait?  Our
> > other CI OSes have slower major version release cycles and longer
> > lives, so it's not quite the same hamster wheel of upgrades.
>
> I'd argue that developers are probably the kind of people who update
> their OS sooner rather than later --- I've usually updated my laptop
> and at least one BF animal to $latest macOS within a month or so of
> the dot-zero release.  So waiting 6 months seems to me like CI will be
> behind the users, which will be unhelpful.  I'd rather drop the oldest
> release sooner, if we need to hold down the number of macOS revisions
> under test.

Cool.  Done.

Out of curiosity, I wondered how the "graphical installer" packagers
like EDB and Postgres.app choose a target, when Apple is moving so
fast.  I see that the current EDB installers target 10.14 for PG15,
which was 5 years old at initial release, and thus already EOL'd for 2
years.  Postgres.app goes back one more year.  In other words, even
though that preadv/pwritev "decl" stuff is unnecessary for PG16 if you
think we should only target OSes that the vendor still supports (which
will be 12, 13, 14), someone would still shout at me if I removed it.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. ci: Add test coverage of different pg_upgrade modes

  2. seg: Add test "security" in meson.build

  3. cirrus/freebsd: define ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS

  4. cirrus/ccache: Use G rather than GB suffix

  5. ci: Upgrade macOS version from 12 to 13.

  6. meson: Add two missing regress tests

  7. Push lpp variable closer to usage in heapgetpage()

  8. ci: Change macOS builds from Intel to ARM.

  9. ci: Introduce SanityCheck task that other tasks depend on

  10. ci: Use -fsanitize=undefined,alignment,address in linux tasks

  11. ci: Clean up pre-meson cruft in windows task

  12. meson: Mark PROVE as not required

  13. ci: enable various runtime checks on FreeBSD and macOS