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

Hi,

On 2026-06-02 15:19:02 +0300, Nazir Bilal Yavuz wrote:
> On Tue, 2 Jun 2026 at 00:57, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > We might want to split the containers further (e.g. cross building and
> 32bit
> > support), but for now I just split the docs stuff into a separate
> container.
>
> Is this really useful? I remember that we merged Windows VM images because
> of the storage costs.

It doesn't really add storage cost here, because this is containers, where the
different containers are layered ontop of each other. That's not the case for
images. With images there also was just no gain, because they don't have to
be pulled fully ahead of time, they were (at least at some point, I think not
initially when we started using them) populated on demand.

> > - In the end I didn't like the matrix all that much, makes it considerably
> > harder to understand everything and the restrictions GHA puts on it are
> just
> > too annoying.
> >
> > I replaced it much more heavy use of yaml anchors/aliases and by
> updating
> > the environment programattically. I'm not sure how much better it is
> now.
>
> I think this is better compared to matrix and closer to what we had with
> Cirrus. One thing I didn't like is that we need to define yaml anchors in
> the jobs, I wish we could define them at the top..

Agreed...

> > - There was too much duplication around the ccache handling for my
> taste. I
> > moved that into a yaml anchor and reused it everywhere. By using
> > ${{github.job_id}} the cache names don't need to be manually
> disambiguated.
> >
> > - The ccache names weren't unique enough. The run_id doesn't change
> during
> > reruns which would lead to warnings.
> >
> > - Made it so that the cache is saved immediately after the build, so
> that
> > cancelled builds still save the cache.
>
> AFAIU, we save cache although the job might fail later. Would that cause
> problems?

I think we explicitly *want* that, as otherwise a job repeatedly failing
causes each attempt to start with a cold cache. Making iterating on the work
more painful.

> > - Deduplicated a few other things like logging.
> >
> >
> > - Added a commit removing cirrus, mainly because I was tired of it also
> > running while hacking on this.
>
> I am not sure that is the actual proposed commit for removing Cirrus but we
> have several more places which mention Cirrus.

It was not yet.

> > - Also added a commit to reduce the segment size in tests to 1MB, that
> makes
> > them a decent bit less IO intensive.
> >
> >
> > - Added a commit to just run regress/regress, makes it a lot faster to
> test
> > "complete-ish" cycles.
>
> I think that would be useful. Perhaps we can enable this with commit
> messages like how 'ci-os-only' is used. I mean something like
> 'ci-test-only:' or such?

The problem is that we have two different ways of phrasing this, for autoconf
and meson...

> > - Changed sanitizer using builds to use -O2, to reduce the CPU cost a bit.
> >
> > This makes uncached builds noticeably slower, but does appear to be a
> > win. But I could see counter-arguments to that too.
> >
> >
> > - Removed :detect_stack_use_after_return=0, as that's been made
> unnecessary
> > since you "forked off" from .cirrus.tasks.yml.
> >
> >
> > A few other comments:
> >
> > - All the caches in GHA apparently are branch specific, except that
> branches
> > can access the caches of the main branch.
> >
> > I think that'll make particularly macports very expensive for cfbot. I
> > wonder if we ought to build the "base" macports cache in pg-vm-images.
> >
> > Similarly, I think we probably should do that for mingw64.
>
> If i understood correctly, you mean that we will push cache to hardcoded
> URL and download caches from the same URL, right? Or do you have something
> else in your mind?

I think we'd have to move the caching into pg-vm-images or such for it to
work...

> I looked at 0002 for now and it looks good to me. I implemented several
> more changes on top of 0002 as 0003 and reattached patches:
>
> - Fixed the cancelling on REL_ branches.

Thanks. I think maybe we should add an && endsWith(..., '_STABLE'), so one
can have WIP progress for stable branches without triggering this (e.g. for
hacking on backports).

> - Used YAML anchors on the CompilerWarnings task.

Nice!

Greetings,

Andres Freund