Re: [PATCH v2 00/12] fsmonitor: Implement fsmonitor for Linux

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Tue, Oct 18 2022, Glen Choo wrote:

> Cc-ed Johannes, who would know a lot more about CI than I do.
>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Glen Choo <chooglen@google.com> writes:
>>
>>> At $DAYJOB, we observed that this topic breaks MacOS builds with sha1dc:
>>
>> Thanks for a report.
>>
>> How dissapointing.  The thing is that the topic has been in 'next'
>> since the 11th (i.e. early last week), and I know that you guys rely
>> on the tip of 'next' in working order to cut your internal releases,
>> but we did not hear about this until now.
>
> Yes. Unfortunately, we (Google's Git team) release on a weekly cadence;
> we merge on Fridays and build on Mondays (PST), which makes this timing
> extremely unfortunate.
>
>> Possible action items:
>>
>>  * See what configurations our two macOS jobs are using.  If neither
>>    is using sha1dc, I would say that is criminal [*] and at least
>>    one of them should be updated to do so right away.
>
> I'm not too familiar with the CI, but I took a quick peek at ci/lib.sh
> and noticed that none of the jobs build with sha1dc, not even the Linux
> or Windows ones, so..

All of our jobs except the OSX one build with SHA1_DC, because it's the
default.

Per my just-sent
https://lore.kernel.org/git/cover-v2-0.4-00000000000-20221019T010222Z-avarab@gmail.com/
the blind spot has been lack fo SHA1_DC on OSX, for others it's the
reverse, we don't test e.g. BLK_SHA1.

In practice we've been catching SHA-implementation specific code early
because the OSX implementation was different, but in this case it's
OSX-only code, so it only supported the Apple Common Crypto backend.

>>  * The "two macOS CI jobs sharing too many configuration knobs" may
>>    not be limited to just SHA-1 implementation, but unlike Linux
>>    builds and tests, we may have similar "monoculture" issue in our
>>    macOS CI builds.  Those users, who depend on macOS port being
>>    healthy, should help identify unnecessary overlaps between the
>>    two, and more importantly, make sure we have CI builds with
>>    configuration similar to what they actually use.
>
> I don't think this is a macOS-specific issue; our CI just doesn't do a
> good job with testing various build configurations.

Yes, definitely.

>>  * Adding a few build-only-without-tests CI jobs also might help.
>
> This sounds like the way to go IMO. It might be too expensive to run the
> full test suite on every build configuration, but build-without-test
> might be ok.

Yes, there's not much point in running the full tests for some of these
variants.

A lot of it we can also get for free, e.g. we run some linux jobs with
clang, some with gcc etc., we could also run one with BLK_SHA1, one with
OPENSSL_SHA1 etc.