Thread

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

Nazir Bilal Yavuz <byavuz81@gmail.com> — 2026-05-28T17:08:39Z

Hi,

Thank you for looking into this!

On Thu, 28 May 2026 at 14:49, Peter Eisentraut <peter@eisentraut.org> wrote:
>
> 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:

I addressed these feedbacks in v3 [1].


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

Done.


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

I think this is better. Also, I merged all Linux tasks and because of
that I needed to add 64 bit and 32 bit to task names. So, I removed
'Debian' from task names because of the same reason you mentioned.


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

I used MacPorts like we did in Cirrus. So, I didn't apply these changes.


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

I think it makes sense.


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

I didn't apply these since MacPorts is used now.


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

Done.


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

I wondered the same thing while working on this.


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

Done.


[1] https://postgr.es/m/CAN55FZ1-qiOWtQH5o6Q_7LJ7S3Ef_hfDE068uP0hGjB3gzwghg%40mail.gmail.com

-- 
Regards,
Nazir Bilal Yavuz
Microsoft