Horton

Re: Building with musl in CI and the build farm

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Wolfgang Walther <walther@technowledgy.de>
Cc: Peter Eisentraut <peter@eisentraut.org>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-04-04T14:36:41Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Allow "make check"-style testing to work with musl C library.

  2. Fix compiler warnings on MSYS2

Wolfgang Walther <walther@technowledgy.de> writes:
> Peter Eisentraut:
>> I think SanityCheck should run a simple, "average" environment, like the 
>> current Debian one.  Otherwise, niche problems with musl or multi-arch 
>> or whatever will throw off the entire build pipeline.

> I do agree: SanityCheck doesn't feel like the right place to put this. 
> But on the other side.. if it really fails to *build* with musl, then it 
> shouldn't make a difference whether you will be notified about that 
> immediately or later in the CI pipeline. It certainly needs the fewest 
> additional resources to put it there.

That is not the concern here.  What I think Peter is worried about,
and certainly what I'm worried about, is that a breakage in
SanityCheck comprehensively breaks all CI testing for all Postgres
developers.  One buildfarm member that's failing does not halt
progress altogether, so it's not even in the same ballpark of
being as critical.  So I agree with Peter that SanityCheck had
better use a very common, vanilla environment.

To be blunt, I do not think we need to test musl in the CI pipeline.
I see it as one of the niche platforms that the buildfarm exists
to test.

			regards, tom lane