Re: [PATCH 0/4] gitlab-ci: fix the cargo invocation in the Windows job

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 22, 2026, 11:50 UTC
Message-ID: <cd4dc991-0791-c4b7-19d1-c45018ccc119@gmx.de>
In-Reply-To: <CAOLa=ZQkJui77Xz2HL4sAWsaYLAzU6EPvBk+RzKkKxoiY_8aKw@mail.gmail.com>

Hi Karthik,

On Mon, 21 Sep 2026, Karthik Nayak wrote:

Show 27 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Sun, 20 Sep 2026, Karthik Nayak wrote:
> >
> >> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >>
> >> > In https://lore.kernel.org/git/xmqq8q4zosri.fsf@gitster.g/, Junio mentioned
> >> > that the GitLab CI seems broken since I enabled Rust in the Windows-based CI
> >> > jobs. This patch series should fix it (lightly tested, but I don't have a
> >> > whole lot of build minutes on GitLab).
> >> >
> >>
> >> I've created an MR [1] on our team repo for testing, I'll try to update
> >> with newer versions (if any). The pipeline for this version is here [2].
> >>
> >> [1]: https://gitlab.com/gitlab-org/git/-/merge_requests/671
> >> [2]: https://gitlab.com/gitlab-org/git/-/pipelines/2863888081
> >
> > Thank you!
> >
> > It looks as if the `build:mingw64` job succeeded, as planned (although it
> > should now probably say `build:ucrt64`?).
> >
> > The `build:msvc-meson` job seems to have timed out trying to do something
> > with credentials, though...
> 
> Re-ran the job and it seems to now run as expected.

Seems that now some `test:msvc-meson` jobs failed. I had a closer look: the failures happened during the cleanup phase. Apparently there is a problematic change in the Runner image:

All failing jobs used Runner 19.4.0~pre.2085.g4d3dddee. Its cleanup code (https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L2081) calls `writeClearGitCredentials()`, which runs `git credential reject`: https://gitlab.com/gitlab-org/gitlab-runner/-/blob/4d3dddee/shells/abstract.go#L758

However, this `git credential reject` then calls _Git Credential Manager_, which assumes that it is running interactively. And that there is anything to reject. And therefore it waits for the user to react to the open dialog, but there is no user, so it times out after two hours.

The successfully-retried build (https://gitlab.com/gitlab-org/git/-/jobs/16625727899) and the passing test slice 3 (https://gitlab.com/gitlab-org/git/-/jobs/16604448474) used Runner **18.8.0**, whose cleanup code (https://gitlab.com/gitlab-org/gitlab-runner/-/blob/v18.8.0/shells/abstract.go#L1699) lacks that credential-clearing call.

Might be worth pointing that out to your colleagues who are in charge of that Runner image?

Ciao, Johannes