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

On 25.05.26 14:14, Nazir Bilal Yavuz wrote:
> On Tue, 19 May 2026 at 01:27, Nazir Bilal Yavuz<byavuz81@gmail.com> wrote:
>> I think we can merge these two patches and move forward that way. I am
>> planning to review your patch and see what I can come up with to get
>> it to a committable state.
> Here is the v2, I took Jelte's patch and reviewed & merged it with my
> patch.

I have tested this patch and inspected the output mostly to make sure 
that there are no regressions about what features and dependency 
versions are being tested (diffed the various logs).  I'm proposing a 
few minor fixups in the attached patch, but other than that (and what 
others have mentioned), this pretty much works well, and I would be 
content to proceed with this or whatever state it's on in a few days.

Some comments in detail:

- Others have already mentioned about the potential for this to conflict 
with downstream uses of GH Actions.  I suggest renaming the file from 
ci.yml to something like postgresql-ci.yml, so that there is no file 
naming conflict or confusion.

- As was already mentioned, the Linux/Meson job is very long (slow) and 
should be split into separate 32/64-bit jobs.

- The job names are too long and get truncated in the UI.  This is 
especially annoying when the important differentiator like "Autoconf" or 
"Meson" gets cut off.  I'm proposing some changes to the job names that 
make them display better.  (Also consider this if you make separate jobs 
for 32/64-bit.  The usable space is about 20 characters.)

- On macOS, there were some dependency differences:

   - readline was not used.
   - tcl-tk (version 9) was used instead of tcl-tk@8.
   - python@3.12 was installed but not actually used in the build.
   - zlib version differed.

   Maybe the zlib difference is not important and could be ignored.
   Also, maybe we don't need to use a versioned python dependency.  (We
   didn't have one before we switched Cirrus from Homebrew to MacPorts.)

- On macOS, the meson setup output reported a significantly different 
sysroot, which was confusing.  I think the sysroot is only used if you 
build against a system perl/python/tcl, which we don't, so I added an 
option to disable the sysroot use.  That way, if we do end up making use 
of the sysroot, someone is forced to investigate this issue.  I don't 
know if this makes sense.

- For macOS, I threw in some HOMEBREW_* environment variables to disable 
some unnecessary additional output or cleanup steps.

- On Windows/VS, we should install winflexbison3 not winflexbison, to 
get an up-to-date version.

- FUTURE: On Windows/VS, we use openssl 1.1, which matches the Cirrus 
setup, so it's ok, but the equivalent buildfarm members all use openssl 
3.*, so we should consider upgrading that sometime to make that more 
consistent.

- On Windows/minGW, I dropped a few packages from the set to be 
installed, which didn't seem necessary.