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