threads / patch / 63361

patchgitlab-ci: always run MSVC-based Meson job

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

## tl;dr

9 messages between Apr 28, 2025 and May 14, 2025. Diffs are folded; open one to read it.

replies: 8people: 4as markdown or json

Patrick Steinhardt· Apr 28, 2025, 09:32 UTC · lore

With 7304bd2bc39 (ci: wire up Visual Studio build with Meson, 2025-01-22) we have introduced a CI job that builds and tests Git with Microsoft Visual Studio via Meson. This job is only being executed by default on GitHub Workflows though -- on GitLab CI it is marked as a "manual" job, so the developer has to actively trigger these jobs.

The consequence of this split is that any breakage specific to this job is only noticed by developers who mainly work with GitHub. Let's improve this situation by also running the job by default on GitLab CI.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
As proposed in [1]. A test run of this pipeline can be found at [2].
Thanks!
Patrick
[1]: <aA8ymUzWM2t0QkFP@pks.im>
[2]: https://gitlab.com/gitlab-org/git/-/merge_requests/349
---
 .gitlab-ci.yml | 1 -
 1 file changed, 1 deletion(-)
Show changes to .gitlab-ci.yml +0 −1
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 4798b283745..bb6d5b976cd 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -173,7 +173,6 @@ build:msvc-meson:
 test:msvc-meson:
   extends: .msvc-meson
   stage: test
-  when: manual
   timeout: 6h
   needs:
     - job: "build:msvc-meson"

---
base-commit: f65182a99e545d2f2bc22e6c1c2da192133b16a3
change-id: 20250428-pks-gitlab-ci-execute-win-meson-e54998fa7081
Johannes Schindelin· Apr 28, 2025, 10:59 UTC · re: Patrick Steinhardt · lore

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

Hi Patrick,
On Mon, 28 Apr 2025, Patrick Steinhardt wrote:
Show 9 quoted lines
> With 7304bd2bc39 (ci: wire up Visual Studio build with Meson,
> 2025-01-22) we have introduced a CI job that builds and tests Git with
> Microsoft Visual Studio via Meson. This job is only being executed by
> default on GitHub Workflows though -- on GitLab CI it is marked as a
> "manual" job, so the developer has to actively trigger these jobs.
> 
> The consequence of this split is that any breakage specific to this job
> is only noticed by developers who mainly work with GitHub. Let's improve
> this situation by also running the job by default on GitLab CI.

The rationale makes sense to me, even if the added runtime (and consumption of resources) is quite contrary to what I would like. 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.

Having said that, with the rationale provided in the commit message, this patch looks good to me.

Ciao, Johannes

Show 32 quoted lines
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> As proposed in [1]. A test run of this pipeline can be found at [2].
> Thanks!
> 
> Patrick
> 
> [1]: <aA8ymUzWM2t0QkFP@pks.im>
> [2]: https://gitlab.com/gitlab-org/git/-/merge_requests/349
> ---
>  .gitlab-ci.yml | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index 4798b283745..bb6d5b976cd 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -173,7 +173,6 @@ build:msvc-meson:
>  test:msvc-meson:
>    extends: .msvc-meson
>    stage: test
> -  when: manual
>    timeout: 6h
>    needs:
>      - job: "build:msvc-meson"
> 
> ---
> base-commit: f65182a99e545d2f2bc22e6c1c2da192133b16a3
> change-id: 20250428-pks-gitlab-ci-execute-win-meson-e54998fa7081
> 
>
Junio C Hamano· Apr 28, 2025, 18:44 UTC · re: Johannes Schindelin · lore

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

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 5 quoted lines
> .... 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.
Patrick Steinhardt· May 6, 2025, 10:39 UTC · re: Junio C Hamano · lore

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

On Mon, Apr 28, 2025 at 11:44:08AM -0700, Junio C Hamano wrote:
Show 13 quoted lines
> 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.

Show 6 quoted lines
> [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
Phillip Wood· May 6, 2025, 13:17 UTC · re: Patrick Steinhardt · lore

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

On 06/05/2025 11:39, Patrick Steinhardt wrote:
Show 14 quoted lines
> On Mon, Apr 28, 2025 at 11:44:08AM -0700, Junio C Hamano wrote:
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
>
Patrick Steinhardt· May 13, 2025, 09:12 UTC · re: Patrick Steinhardt · lore

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

On Mon, Apr 28, 2025 at 11:32:12AM +0200, Patrick Steinhardt wrote:
Show 11 quoted lines
> With 7304bd2bc39 (ci: wire up Visual Studio build with Meson,
> 2025-01-22) we have introduced a CI job that builds and tests Git with
> Microsoft Visual Studio via Meson. This job is only being executed by
> default on GitHub Workflows though -- on GitLab CI it is marked as a
> "manual" job, so the developer has to actively trigger these jobs.
> 
> The consequence of this split is that any breakage specific to this job
> is only noticed by developers who mainly work with GitHub. Let's improve
> this situation by also running the job by default on GitLab CI.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>

While there has been discussion around whether we can in general avoid some duplication in our pipelines, I think this patch makes sense regardless to bring GitLab CI in line with GitHub Workflows. I haven't seen the patch being picked up yet though -- I assume it fell of the radar.

Junio, do you have any concern with taking this patch?
Thanks!
Junio C Hamano· May 13, 2025, 17:03 UTC · re: Patrick Steinhardt · lore

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

Patrick Steinhardt <ps@pks.im> writes:
Show 20 quoted lines
> On Mon, Apr 28, 2025 at 11:32:12AM +0200, Patrick Steinhardt wrote:
>> With 7304bd2bc39 (ci: wire up Visual Studio build with Meson,
>> 2025-01-22) we have introduced a CI job that builds and tests Git with
>> Microsoft Visual Studio via Meson. This job is only being executed by
>> default on GitHub Workflows though -- on GitLab CI it is marked as a
>> "manual" job, so the developer has to actively trigger these jobs.
>> 
>> The consequence of this split is that any breakage specific to this job
>> is only noticed by developers who mainly work with GitHub. Let's improve
>> this situation by also running the job by default on GitLab CI.
>> 
>> Signed-off-by: Patrick Steinhardt <ps@pks.im>
>
> While there has been discussion around whether we can in general avoid
> some duplication in our pipelines, I think this patch makes sense
> regardless to bring GitLab CI in line with GitHub Workflows. I haven't
> seen the patch being picked up yet though -- I assume it fell of the
> radar.
>
> Junio, do you have any concern with taking this patch?

As long as Windows stakeholders are happy with the change, I have no objection. I didn't pick it up simply because Dscho didn't sound too happy, and I do not take "The code seems to be correct, but I do not like what it does" as a positive endorsement.

Thanks.
Patrick Steinhardt· May 14, 2025, 02:16 UTC · re: Junio C Hamano · lore

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

On Tue, May 13, 2025 at 10:03:46AM -0700, Junio C Hamano wrote:
Show 27 quoted lines
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > On Mon, Apr 28, 2025 at 11:32:12AM +0200, Patrick Steinhardt wrote:
> >> With 7304bd2bc39 (ci: wire up Visual Studio build with Meson,
> >> 2025-01-22) we have introduced a CI job that builds and tests Git with
> >> Microsoft Visual Studio via Meson. This job is only being executed by
> >> default on GitHub Workflows though -- on GitLab CI it is marked as a
> >> "manual" job, so the developer has to actively trigger these jobs.
> >> 
> >> The consequence of this split is that any breakage specific to this job
> >> is only noticed by developers who mainly work with GitHub. Let's improve
> >> this situation by also running the job by default on GitLab CI.
> >> 
> >> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> >
> > While there has been discussion around whether we can in general avoid
> > some duplication in our pipelines, I think this patch makes sense
> > regardless to bring GitLab CI in line with GitHub Workflows. I haven't
> > seen the patch being picked up yet though -- I assume it fell of the
> > radar.
> >
> > Junio, do you have any concern with taking this patch?
> 
> As long as Windows stakeholders are happy with the change, I have no
> objection.  I didn't pick it up simply because Dscho didn't sound
> too happy, and I do not take "The code seems to be correct, but I do
> not like what it does" as a positive endorsement.

I don't think Dscho pays much attention to the GitLab CI anyway, so it ultimately doesn't matter too much for him. This is not criticism by the way, it should ideally be interchangable whether anybody looks at GitHub or GitLab CI. So by making the GitLab CI run those jobs by default we make the CI systems more interchangable.

I expect that this should help us at GitLab to decrease Dscho's load as we would see the same kind of breakage that he needs to worry about every day. And being the primary drivers for the Meson build system I think it's only fair that we help out with fixing any issues that happen in the Win+Meson jobs.

Patrick
Junio C Hamano· May 14, 2025, 16:55 UTC · re: Patrick Steinhardt · lore

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

Patrick Steinhardt <ps@pks.im> writes:
Show 5 quoted lines
> I expect that this should help us at GitLab to decrease Dscho's load as
> we would see the same kind of breakage that he needs to worry about
> every day. And being the primary drivers for the Meson build system I
> think it's only fair that we help out with fixing any issues that happen
> in the Win+Meson jobs.
Alright.  Let's merge it down.

← back to recent threads