Message-ID: <9b7cc292-9feb-46c9-af2c-ecd55fbd413a@technowledgy.de>
Date: Thu, 4 Apr 2024 21:09:30 +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: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>,
 Andres Freund <andres@anarazel.de>,
 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>
 <c2e81ddf-747a-420f-ab7f-1c545c8bc59c@technowledgy.de>
 <545893.1712241401@sss.pgh.pa.us>
 <12606570-50cc-4e66-9c5c-d9e61764551d@technowledgy.de>
 <562618.1712243951@sss.pgh.pa.us>
In-Reply-To: <562618.1712243951@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/9b7cc292-9feb-46c9-af2c-ecd55fbd413a%40technowledgy.de>
Precedence: bulk

Tom Lane:
>> You'd have to commit a failing patch first to break CI for all other
>> developers.
> 
> No, what I'm more worried about is some change in the environment
> causing the build to start failing.  When that happens, it'd better
> be an environment that many of us are familiar with and can test/fix.

The way I understand how this work is, that the images for the VMs in 
which those CI tasks run, are not just dynamically updated - but are 
actually tested before they are used in CI. So the environment doesn't 
just change suddenly.

See e.g. [1] for a pull request to the repo containing those images to 
update the linux debian image from bullseye to bookworm. This is exactly 
the image we're talking about. Before this image is used in postgres CI, 
it's tested and confirmed that it actually works there. If one of the 
jobs was using musl - that would be tested as well. So this job would 
not just suddenly start failing for everybody.

I do see the "familiarity" argument for the SanityCheck task, but for a 
different reason: Even though it's unlikely for this job to fail for 
musl specific reasons - if you're not familiar with musl and can't 
easily test it locally, you might not be able to tell immediately 
whether it's musl specific or not. If musl was run in one of the later 
jobs, it's much different: You see all tests failing - alright, not musl 
specific. You see only the musl test failing - yeah, musl problem. This 
should give developers much more confidence looking at the results.

Best,

Wolfgang

[1]: https://github.com/anarazel/pg-vm-images/pull/91