Cc-ed Johannes, who would know a lot more about CI than I do. Junio C Hamano <gitster@xxxxxxxxx> writes: > Glen Choo <chooglen@xxxxxxxxxx> 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.. > * 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. > * 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. > * Those who depend on working macOS port, especially those with > corporate backing who choose to use configurations that are > different from what we have CI builds for, are requested to > arrange a more frequent build test to catch a problem like this > much earlier. I wished we had caught it sooner too. The folks here generally agree that our weekly release cycle is not ideal for reasons such as this. Hopefully this is good motivation to move that work forward, though I can't promise anything right now. > Anything else I forgot that we can do to improve the situation? I > personally do not use macOS, I am not interested in using one, but > I do value those who choose to use macOS have happy git working on > their platform, so the stakeholders need to chip in. There's nothing else I can think of at the moment. Thanks for your patience and for moving the conversation along. > > Thanks. > > > [Footnote] > > * Until the world migrates over to SHA-256, the collision detecting > SHA-1 implementation is what we must use unless there is a strong > reason not to. If we are not testing something that ought to be > the default, we are not doing a very good job.
