Conversation
The minimal Git for Windows SDK already supplies Git and GCC. The MinGW Makefile build needs the GNU Rust toolchain, not another Git installation or Meson. Let the dependency installer serve this configuration while keeping the existing package set for MSVC builds. Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Creating .git/info/exclude as a file with `New-Item` and `-Force` truncates existing contents. When install-dependencies.ps1 follows install-sdk.ps1, this discards the latter's /git-sdk exclusion and causes ci/lib.sh to reject SDK files as unignored build artifacts. Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GitLab's MinGW job fails with "cargo: command not found": https://gitlab.com/git-scm/git/-/jobs/16576450182 86909a9 (ci(windows): build with Rust, 2026-09-13) enabled Rust in the shared CI configuration, but added the necessary setup only for GitHub Actions. The build needs Cargo to be reachable after the minimal SDK's login profile replaces PATH. Installing the toolchain alone is not enough. Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
GitLab's MinGW job cannot find `x86_64-w64-mingw32-gcc` when linking gitcore's build script: https://gitlab.com/dscho/git1/-/jobs/16593470275 Although gitcore is a static library, Cargo first links `build.rs` as a host executable. We omitted the GNU MSI's `Gcc` feature, which supplies the required linker and platform libraries: https://github.com/rust-lang/rust/blob/1.96.0/src/etc/installer/msi/rust.wxs Assisted-by: GPT-6 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Member
Author
|
/submit |
|
Submitted as pull.2233.git.1789819933.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
Karthik Nayak wrote on the Git mailing list (how to reply to this email): "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
> Johannes Schindelin (4):
> ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
> ci(gitlab,windows): preserve exclusions during dependency setup
> ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
> ci(gitlab,windows): provide GNU Rust's host-linker support
>
> .gitlab-ci.yml | 5 ++++-
> ci/install-dependencies.ps1 | 22 ++++++++++++++++------
> 2 files changed, 20 insertions(+), 7 deletions(-)
>
>
> base-commit: d38352cd43ab9745686d697872408bc3249a153f
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2233%2Fdscho%2Ffix-cargo-in-windows-gitlab-ci-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2233/dscho/fix-cargo-in-windows-gitlab-ci-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/2233
> --
> gitgitgadget |
|
User |
|
Johannes Schindelin wrote on the Git mailing list (how to reply to this email): Hi Karthik,
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...
Ciao,
Johannes |
|
Karthik Nayak wrote on the Git mailing list (how to reply to this email): Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi Karthik,
>
> 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.
>
> Ciao,
> Johannes |
|
Johannes Schindelin wrote on the Git mailing list (how to reply to this email): Hi Karthik,
On Mon, 21 Sep 2026, Karthik Nayak wrote:
> 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 |
|
This branch is now known as |
|
This patch series was integrated into seen via git@adb58b7. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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).
Cc: Patrick Steinhardt ps@pks.im
cc: Karthik Nayak karthik.188@gmail.com