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

Hi,

On Tue, 2 Jun 2026 at 00:57, Andres Freund <andres@anarazel.de> wrote:
>
> Attached is an large incremental patch onto Bilal's version:

Thank you!


> - I hacked enough on the pg-vm-images repo to make it store containers in
>   github (on the gha_main branch, for now).  That makes the container
faster
>   and cheaper to retrieve.

Nice.


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


> - The reason that sometimes cancelling took a long time was, afaict, the
use
>   of always() in the compiler-warning job. That apparently prevents GHA
from
>   cancelling the job in a timely fashion. I turned those into
!cancelled().
>
>   Also addded a !cancelled() to SanityCheck.

That makes sense.


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


> - The macports cache keys included the run_id, I think that's a bad idea,
>   because it leads to the cache being newly uploaded even if there's been
no
>   change. That'll lead to even more quickly churning through the cache
space.

That makes sense.


> - ccache:
>
>   - 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 wanted to share commands like meson test between the tasks, made that
work
>   with a bit of hackery.
>
>
> - I didn't see why
>     find / -maxdepth 1 -type f -name 'core*' -exec mv '{}' /tmp/cores/ \;
>   was needed.

I think the reasoning is that we don't have a 'setup_core_files_script'
step on the Cirrus' SanityCheck. I agree we don't need this now.


> - I found it hard to find actual warnings in the output of
CompilerWarnings,
>   due to to all the configure output. I added some magic output stuff to
make
>   the configure output collapse once it ran.

Adding a comment explaining what these echos for would be useful but I
couldn't find a nice place to add a comment. Perhaps the first use of these
echos?


> - I converted most things to use ${{env.varname}} instead of $VARNAME or
>   %VARNAME%, as that allows sharing code between windows and other OSs if
one
>   is a bit careful.

Nice.


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


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


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


> - src/tools/ci/README needs updating

Yes, with several other files:
- src/bin/pg_combinebackup/t/010_hardlink.pl
- src/test/perl/PostgreSQL/Test/Cluster.pm
- src/tools/ci/gcp_ram_disk.sh (Do we need to remove this? I am not sure we
will use this when we have BSDs on GHA.)


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.
- Used YAML anchors on the CompilerWarnings task.


-- 
Regards,
Nazir Bilal Yavuz
Microsoft