Message-ID: <c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de>
Date: Thu, 4 Apr 2024 16:11:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Wolfgang Walther <walther@technowledgy.de>
Subject: Re: Building with musl in CI and the build farm
Content-Language: en-US
To: Peter Eisentraut <peter@eisentraut.org>,
 Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.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>
In-Reply-To: <7764f41f-29f6-428f-b40d-43ba2da38170@eisentraut.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c2e81ddf-747a-420f-ab7f-1c545c8bc59c%40technowledgy.de>
Precedence: bulk

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