Re: ci: update to freebsd 13.1 / remove minor versions from image names

Hi,

On 2022-08-01 10:07:32 +1200, Thomas Munro wrote:
> > > I suspect it'd be better to remove the minor version numbers from the
> > > image name, so that switches from 13.0 -> 13.1 don't require CI
> > > changes. Any argument against?
>
> Yeah, that makes sense; it'd remove the need for commits like that.
> For comparison, the Debian image is Bullseye AKA 11.x without the x in
> the name.

Cool, doing that in https://github.com/anarazel/pg-vm-images/pull/15

There's now "freebsd-13" and "netbsd-9-postgres", "openbsd-7-postgres". The
latter two include the -postgres because we have to generate the "base" image
ourselves, because neither net nor openbsd provide a gcp image themselves. Not
that we use net/openbsd images in PG itself yet (I'm about to merge
open/netbsd support in the meson branch though).

> > > I can also see an argument for not having 13 in the image name, given
> > > that the image is CI specific anyway? But perhaps we might want to have
> > > a 13 and a 14 image for some debugging issue?
>
> I'm not sure about this. I could imagine a naming scheme that has
> sensible options available as pg-ci-{debian,freebsd,...}-default, and
> those images are currently the same as
> pg-ci-{debian-11,freebsd-13,...} but can be re-pointed as appropriate
> without having to modify the .cirrus.yml, and someone investigating a
> problem where they really care about the major version could change
> their .cirrus.yml to point to the versioned name.

There's such a concept for gcp, namely "image families". But we already use
that for pg-ci-bullseye etc - each individual image has a name including the
date. There's only one level of families afaiu. We of course could manually
copy images, but that's probably not worth it (and would come with storage
costs).

E.g. pg-ci-bullseye currently points to pg-ci-bullseye-2022-07-31t21-31.

> I don't have a concrete example, but I have a strange feeling in my big toe
> that it'd be better to state the major version explicitly, and have a few
> available...

FWIW, at the moment all images are deleted after two weeks ([1]). We probably
can make that smarter and not delete the newest image for a family, even if
that image is older than two weeks. Not that the gcp API seems to make that
easy.

Greetings,

Andres Freund

[1] https://github.com/anarazel/pg-vm-images/blob/main/.cirrus.yml#L209