Re: [PATCH] gitlab-ci: always run MSVC-based Meson job

[Patrick Steinhardt <ps@pks.im>]

On Mon, Apr 28, 2025 at 11:44:08AM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > .... From my
> > point of view, Git is spending way more compute than is warranted. The way
> > Git's CI builds are set up, in many cases a single regression will cause
> > many tests/jobs to fail, and that indicates to me that Git's CI definition
> > (and even Git's test suite) contains too many redundant parts.
> 
> While I also feel frustrated by watching paint dry after pushing
> day's integration results out, and often seeing that multiple CI
> jobs fail due to the same breakage in 'seen' I do feel if there are
> ways to avoid such waste, I do not think of a good way to do so [*].
> Are there some concrete proposals?

We could probably combine at least some CI jobs. The "pedantic" Fedora
job for example feels rather weird because it just builds without
testing anything. It could be merged into one of the other jobs by
executing tests on Fedora instead, with pedantic compiler flags. But
other than that I don't really have any other good ideas.

> [Footnote]
> 
>  * For example, if gitlab-ci and github-ci run the same CI jobs on
>    the same exact revision of Git using the same exact docker image,
>    if there is no reason to expect one to succeed and one to fail,
>    perhaps we can drop one and keep the other? 

At GitLab we will definitely want to have a full pipeline for Git given
that we use a merge request-based workflow all the time. So if parts of
the GitLab CI went away, we would have to handroll it again and backfill
any jobs that went missing to enable our own workflow.

While it's inefficient to have the same pipeline effectively run twice,
this is the kind of behaviour you get in a distributed system, I guess.

>    Or perhaps we pick a
>    single representative job and only after it passes start other
>    jobs?  None of the tweaks along these lines I can think of feel
>    satisfying to me.

Wouldn't that only mean that the pipeline takes even longer from start
to finish? Even if the representative job succeeds it doesn't tell me
anything about whether there are leaks, or whether it works on Windows,
or on macOS. But given that I am on Linux, I especially care about jobs
that use a platform different than my own and always wait for them to
finish before sending out a patch series to the mailing list.

Patrick