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

help / color / mirror / Atom feed
From: Wolfgang Walther <walther@technowledgy.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: 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 21:09:30 +0200
Message-ID: <9b7cc292-9feb-46c9-af2c-ecd55fbd413a@technowledgy.de> (raw)
In-Reply-To: <562618.1712243951@sss.pgh.pa.us>
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>

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





view thread (10+ messages)

Message-ID: <9b7cc292-9feb-46c9-af2c-ecd55fbd413a@technowledgy.de>
Permalink:  ../9b7cc292-9feb-46c9-af2c-ecd55fbd413a@technowledgy.de/
Also on:    postgresql.org/message-id/9b7cc292-9feb-46c9-af2c-ecd55fbd413a@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, tgl@sss.pgh.pa.us, peter@eisentraut.org, andres@anarazel.de, pgsql-hackers@postgresql.org
  Subject: Re: Building with musl in CI and the build farm
  In-Reply-To: <9b7cc292-9feb-46c9-af2c-ecd55fbd413a@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