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

Johannes Schindelin [off-list ref] 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?

Thanks.

[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?  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.

On Mon, Apr 28, 2025 at 11:44:08AM -0700, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

.... 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

On 06/05/2025 11:39, Patrick Steinhardt wrote:

On Mon, Apr 28, 2025 at 11:44:08AM -0700, Junio C Hamano wrote:

quoted

Johannes Schindelin [off-list ref] writes:

    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.

I did wonder if it is possible to make a failing job kill/cancel all the other jobs but I think we have a few flaky tests that occasionally randomly fail which complicates things.

Best Wishes

Phillip

Patrick