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

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Nazir Bilal Yavuz <[email protected]>
To: Peter Eisentraut <[email protected]>
Cc: Jelte Fennema-Nio <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: [email protected]
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Date: Thu, 28 May 2026 20:08:39 +0300
Message-ID: <CAN55FZ2rHVOxUS_jwo477kd0nVO9R-98pV5P+oWkt5taRRinGw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <3ydjipcr7kbss57nvi67noplncqhesl5eyb6wgol4ccjxynspv@yatlykpribmm>
	<[email protected]>
	<CAN55FZ30Np67cATsqYxF1SsP598VoRv4hJQZ4w9RA3Qe55prnQ@mail.gmail.com>
	<CAN55FZ13uX0cLSbgtSnnFeh5sTLeMr7+8UzmqpU6QjOtrRJTLg@mail.gmail.com>
	<[email protected]>

Hi,

Thank you for looking into this!

On Thu, 28 May 2026 at 14:49, Peter Eisentraut <[email protected]> wrote:
>
> On 25.05.26 14:14, Nazir Bilal Yavuz wrote:
> > On Tue, 19 May 2026 at 01:27, Nazir Bilal Yavuz<[email protected]> 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.
>    - [email protected] 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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
  In-Reply-To: <CAN55FZ2rHVOxUS_jwo477kd0nVO9R-98pV5P+oWkt5taRRinGw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox