Re: Building with musl in CI and the build farm

From: Wolfgang Walther <walther(at)technowledgy(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Building with musl in CI and the build farm
Date: 2024-04-04 15:01:32
Message-ID: 12606570-50cc-4e66-9c5c-d9e61764551d@technowledgy.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Tom Lane:
> 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.

You'd have to commit a failing patch first to break CI for all other
developers. If you're only going to commit patches that pass those CI
tasks, then this is not going to happen. Then it only becomes a question
of how much feedback *you* get from a single CI run of your own patch.

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

I don't really have an opinion on this. I'm fine with having musl in the
buildfarm only. I don't expect the core build itself to fail with musl
anyway, this has been working fine for years. Andres asked for it to be
added to CI, so maybe he sees more value on top of just "building with
musl"?

Best,

Wolfgang

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-04-04 15:19:11 Re: Building with musl in CI and the build farm
Previous Message Tom Lane 2024-04-04 14:36:41 Re: Building with musl in CI and the build farm

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-04 15:16:28 Re: WIP Incremental JSON Parser
Previous Message Tom Lane 2024-04-04 15:00:15 Re: WIP Incremental JSON Parser