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

Hi,

On Wed, 10 Jun 2026 at 17:55, Andres Freund <andres(at)anarazel(dot)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.

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

> There's other issues, but I'm not sure we need to resolve them before
> backpatching:
>
> - Coverage for the BSDs - this is complicated enough that I'm not sure it's
> worth backpatching.
>
> I'm on the fence.

I think the current pg-ci.yml file is complicated enough. We can have
BSD support and their back-patches all together later.

> - It's too much work to see what all failed across all the jobs. I've
> experimented with generating a markdown summary across the jobs that ran
> (basically a table that shows which steps succeeded and how many tests
> failed/skipped/timed out, as well as the name of the first failed test).
>
> It does require not entirely trivial changes. But it does make it faster to
> grasp what's going on. It also perhaps is interesting for cfbot /
> commitfest app, because it'd basically would include a summary of which
> steps failed and how many tests passed/failed/... as an output of each job
> and then the workflow.
>
> That's a pretty substantial QOL improvement,

I agree. Also, since this doesn't change any behavior, it would be
(hopefully) easier to test & review this compared to other
improvements.

> - Right now all logs get uploaded. That's quite the waste of space for
> artifacts. Bilal has sent a patch: [2]
>
> But this isn't a new problem, so perhaps it's ok to leave this for later?

Definitely. Main purpose of this patch was reaching failed tests' logs
easily rather than saving a space. It is still a nice gain but this
can wait.

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

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

--
Regards,
Nazir Bilal Yavuz
Microsoft