Re: Heads Up: cirrus-ci is shutting down June 1st

Hi,

Here's a series implementing a lot, but not all, that I brought up.  See the
commit messages for details.  One change that I hadn't mentioned on here is
that I increased the compiler optimizations for mingw, which improves the test
runtimes by a enough to even offset the cold-ccache compile times.


I for now used the setup-msys2 action, with a pin to the SHA to address
Jacob's concern (even though I still don't see what it buys us).

I did try creating an archive of an install, but that ends up with a good bit
of additional complexity, because the installations aren't relocatable (there
are header paths that are patched during install, apparently). And where the
install should be depends on the runner type, larger runners don't have D:,
but slower runners require using D:.  I think Bilal hacked further on my
experiments around this, but I don't quite know where that stands. It's
certainly not a trivial change.


I'm pretty agnostic whether we want 0005, I just included that because it
looks a bit nicer.


On 2026-06-12 16:44:25 +0300, Nazir Bilal Yavuz wrote:
> On Wed, 10 Jun 2026 at 17:55, Andres Freund <andres@anarazel.de> wrote:
> >
> > Before we can backpatch the CI support I think we need to resolve a few more
> > things:
> >
> > - re-enabling crash reporting for windows, Bilal sent a patch [1]
> >
> >   I think that's pretty much a must have, otherwise debuggin windows issues is
> >   really hard.
> 
> That seems working based on my testing, just needs a review.

I'll merge it, I think it's good to go.


> > - Cold or inapplicable (e.g. due to a core header change) compiler warnings
> >   task is very slow (35min).  I have a patch that I need to send out to
> >   convert everything but the headercheck in compilerwarnings to meson, that
> >   reduces the worst case build times considerably (primarily due to the cross
> >   build being able to use precompiled headers)
> >
> >   I'll try to send that out later today.
> 
> Nice. I encountered this problem a couple of times and they were frustrating.

Yea, it's definitely not great as-is.  It's a bit weird that with the patch
above we still use both meson and autoconf (for headerscheck), but I think
it's ok for now.



> > - I comparison to cirrus-ci it's considerably more painful (and it wasn't
> >   exactly pain-free on cirrus either) to access the logs of failed tasks. One
> >   can't just link to the failure or such.
> >
> >   I have wondered about determining which test failed first, and uploading the
> >   most crucial logs for that test separately, so one could at least look and
> >   link to those without unpacking a .zip.
> 
> I have questions about this. If we do this for all jobs then we can
> end up having just too many uploaded files to look at. In this case,
> unpacking .zip would be easier to access the logs of failed tasks.

I was thinking we'd do this only for the first failure...


> > - A decent chunk of test time is spent setting up the containers (I've
> >   optimized them a bit to reduce that already).  Somehow docker is pretty slow
> >   around container extraction.  I had already split the containers into one
> >   for docs and one for the rest, if we did that further, we could make startup
> >   of e.g. sanitycheck (which has an outsized impact) a decent bit faster, but
> >   we can't use the same container for e.g. linux-meson-32.
> >
> >   I think it may be smart to just add per-task tags for the containers. Then
> >   we can have them initially be the same (by just pushing the same container
> >   with different tags), which would allow us to adjust the containers contents
> >   later, without needing to patch the workflow in the postgres repo.
> >
> >   I suspect we should do the tag aliases before backpatching, but I'm very
> >   willing to be convinced otherwise.
> 
> It would make sense to do this before backpatching as some of the
> improvements can be done on the images themselves, which can speed up
> the process.

I did that on the container generation side and now attached a patch to use
them.  It does reduce the time a decent bit.

Greetings,

Andres Freund