Re: CI and test improvements

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
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-02T01:12:12Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes:
> Some observations:

> * macOS has a new release every year in June[1]
> * updates cease after three years[1]
> * thus three releases are in support (by that definition) at a time
> * we need an image on Cirrus; 13 appeared ~1 month later[2]
> * we need Homebrew support; 13 appeared ~3 months later[3]
> * we have 13 and 12 in the buildfarm, but no 11
> * it's common for developers but uncommon for servers/deployment

> 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.

			regards, tom lane



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