pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Wolfgang Walther <walther@technowledgy.de>
To: Peter Eisentraut <peter@eisentraut.org>
To: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Building with musl in CI and the build farm
Date: Thu, 4 Apr 2024 16:11:56 +0200
Message-ID: <c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de> (raw)
In-Reply-To: <7764f41f-29f6-428f-b40d-43ba2da38170@eisentraut.org>
References: <4093813.1710899588@sss.pgh.pa.us>
	<CA+hUKGKNK5V8XwwJJZm36s3EUy8V51xu4XiE8=26n=Wq3OGd4A@mail.gmail.com>
	<4095435.1710900216@sss.pgh.pa.us>
	<CA+hUKGK2cSx3dveMqBD+E9N=zJ0WawBcbk_jnPqmdWBM0DT_3Q@mail.gmail.com>
	<477fa513-6bf0-456d-8d24-1e22a19df671@technowledgy.de>
	<ZfrmN4WHuJgD95fw@momjian.us>
	<CA+hUKGJzC4rr2Yr=QZyx9W83Wv=TVJHndKF1anjNLNXVUM7TqQ@mail.gmail.com>
	<f98cd8de-1c66-491a-8409-e62c09932080@technowledgy.de>
	<20240322001948.atp2eetusylgjyw2@awork3.anarazel.de>
	<40543180-a0a2-495b-8d34-23b46c28f533@technowledgy.de>
	<20240326001447.wcatfvx45tkmizji@awork3.anarazel.de>
	<0a48d551-50e1-4bd3-8d46-8421e3b1b724@technowledgy.de>
	<cfd3d974-d3e7-4adf-9574-0094044e91a4@technowledgy.de>
	<7764f41f-29f6-428f-b40d-43ba2da38170@eisentraut.org>

Peter Eisentraut:
> On 31.03.24 15:34, walther@technowledgy.de wrote:
>>> I'd rather adapt one of the existing tasks, to avoid increasing CI 
>>> costs unduly.
>>
>> I looked into this and I think the only task that could be changed is 
>> the SanityCheck.
> 
> 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.

All the errors/problems I have seen so far, while setting up the 
buildfarm animal on Alpine Linux, have been way beyond what SanityCheck 
does. Problems only appeared in the tests suites, of which sanity check 
only runs *very* basic ones. I don't have much experience with the 
"cross" setup, that "musl on debian" essentially is, though.

All those things are certainly out of scope for CI - they are tested in 
the build farm instead.

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.

I'm not sure what Andres meant with "adopting one of the existing 
tasks". It could fit as another step into the "Linux - Debian Bullseye - 
Autoconf" task, too. A bit similar to how the meson task build for 32 
and 64bit. This would still not be an entirely new task like I proposed 
initially (to run in Docker).

Best,

Wolfgang





view thread (10+ messages)  latest in thread

Message-ID: <c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de>
Permalink:  ../c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de/
Also on:    postgresql.org/message-id/c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de

 · 

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: pgsql-bugs@postgresql.org
  Cc: walther@technowledgy.de, peter@eisentraut.org, andres@anarazel.de, pgsql-hackers@postgresql.org
  Subject: Re: Building with musl in CI and the build farm
  In-Reply-To: <c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de>

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

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