gitlab-ci: fix the cargo invocation in the Windows job

PATCH Superseded Johannes Schindelin via GitGitGadget 5 participants 27 messages Sep 19 – Sep 28

Share & tools

Johannes Schindelin via GitGitGadget

author

2026-09-19 12:12 UTC #0 lore raw

cover gitlab-ci: fix the cargo invocation in the Windows job

In https://lore.kernel.org/git/[email protected]/, 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).

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

Signature · 1 line

gitgitgadget

Johannes Schindelin via GitGitGadget

author

2026-09-19 12:12 UTC #1 lore raw

PATCH 1/4 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

From: Johannes Schindelin <[email protected]>

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 <[email protected]>

---
 ci/install-dependencies.ps1 | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

ci/install-dependencies.ps1 +13 -5

index e3b367fa54..8c68fb0cfc 100755
@@ -1,5 +1,6 @@
 param(
-    [string]$DownloadDirectory = '.dependencies'
+    [string]$DownloadDirectory = '.dependencies',
+    [switch]$Mingw
 )
 
 $ErrorActionPreference = 'Stop'

@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"

@@ -49,7 +61,3 @@ Invoke-Installer $gitInstaller @('-y', '-o"C:\Program Files\Git"')
 $mesonMsi = Get-Installer "meson.msi" `
     "https://github.com/mesonbuild/meson/releases/download/$MesonVersion/meson-$MesonVersion-64.msi"
 Invoke-Installer msiexec.exe @('/i', $mesonMsi, 'INSTALLDIR=C:\Meson', '/quiet', '/norestart')
-
-$rustMsi = Get-Installer "rust.msi" `
-    "https://static.rust-lang.org/dist/rust-$RustVersion-x86_64-pc-windows-msvc.msi"
-Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust', 'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')

Signature · 1 line

gitgitgadget

Patrick Steinhardt

2026-09-24 11:21 UTC #2 lore raw

Re: [PATCH 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

Quoted 5 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>
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.

Huh, what's GNU Rust?

Quoted 2 lines

Let the dependency installer serve this configuration while keeping the existing package set for MSVC builds.

Okay. What's implicit here is that we in fact don't use this script at all at the current point in time for our MinGW build, we rather use the "install-sdk.ps1" script. I assume it will be wired up in the next step, so let's read on.

Quoted 12 lines

ci/install-dependencies.ps1 +4 -0

index e3b367fa54..8c68fb0cfc 100755
@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")

ci/install-dependencies.ps1 function Invoke-Installer { · line 58

Quoted 10 lines

ci/install-dependencies.ps1 +7 -0

+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"

Okay, so installing Rust is the only thing we will want to do on both MSVC and MinGW builds.

Patrick

Johannes Schindelin

2026-09-24 19:26 UTC #3 lore raw

Re: [PATCH 1/4] ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

Hi Patrick,

Quoted 8 lines · Patrick Steinhardt

Quoted 5 lines · Johannes Schindelin via GitGitGadget
From: Johannes Schindelin <[email protected]>
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.
Huh, what's GNU Rust?

Sorry, poor wording. I meant the Rust toolchain compatible with GCC (as opposed to the Rust toolchain producing Visual C-compatible libraries).

Will reword. Using git history reword, thank you so much for that!

Quoted 7 lines

Quoted 2 lines
Let the dependency installer serve this configuration while keeping the existing package set for MSVC builds.
Okay. What's implicit here is that we in fact don't use this script at all at the current point in time for our MinGW build, we rather use the "install-sdk.ps1" script. I assume it will be wired up in the next step, so let's read on.

Correct. Will clarify the commit message.

Quoted 17 lines

ci/install-dependencies.ps1 +9 -0

index e3b367fa54..8c68fb0cfc 100755
@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return

Quoted 8 lines

ci/install-dependencies.ps1 function Invoke-Installer { · line 58
Quoted 5 lines
ci/install-dependencies.ps1 +2 -0
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"
Okay, so installing Rust is the only thing we will want to do on both MSVC and MinGW builds.

Precisely (or as Claude would say: You're absolutely right!), Johannes

Johannes Schindelin via GitGitGadget

author

2026-09-19 12:12 UTC #4 lore raw

PATCH 2/4 ci(gitlab,windows): preserve exclusions during dependency setup

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>

---
 ci/install-dependencies.ps1 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

ci/install-dependencies.ps1 +3 -1

index 8c68fb0cfc..f6868dc670 100755
@@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
 
 New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
 New-Item -Path .git/info -ItemType Directory -Force | Out-Null
-New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
+if (-not (Test-Path .git/info/exclude)) {
+    New-Item -Path .git/info/exclude -ItemType File | Out-Null
+}
 Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"
 
 function Get-Installer {

Signature · 1 line

gitgitgadget

Patrick Steinhardt

2026-09-24 11:21 UTC #5 lore raw

Re: [PATCH 2/4] ci(gitlab,windows): preserve exclusions during dependency setup

Quoted 8 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>
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.

Okay, this confirms that it's indeed the plan to start calling this script for MinGW builds, too.

ci/install-dependencies.ps1 $RustVersion = '1.96.0' · line 18

Quoted 13 lines

ci/install-dependencies.ps1 +3 -1

index 8c68fb0cfc..f6868dc670 100755
@@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
 
 New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
 New-Item -Path .git/info -ItemType Directory -Force | Out-Null
-New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
+if (-not (Test-Path .git/info/exclude)) {
+    New-Item -Path .git/info/exclude -ItemType File | Out-Null
+}
 Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"

Makes sense.

Patrick

Johannes Schindelin via GitGitGadget

author

2026-09-19 12:12 UTC #6 lore raw

PATCH 3/4 ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

GitLab's MinGW job fails with "cargo: command not found":
https://gitlab.com/git-scm/git/-/jobs/16576450182

86909a94db5d (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 <[email protected]>

---
 .gitlab-ci.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

.gitlab-ci.yml +4 -1

index cd6fd4a504..3f24835500 100644
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
   artifacts:
     paths:
       - artifacts

Signature · 1 line

gitgitgadget

Patrick Steinhardt

2026-09-24 11:22 UTC #7 lore raw

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

.gitlab-ci.yml build:mingw64: · line 136

Quoted 9 lines · Johannes Schindelin via GitGitGadget

.gitlab-ci.yml +1 -0

index cd6fd4a504..3f24835500 100644
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw

I wonder whether it would now make sense to also hoist "install-sdk.ps1" into "install-dependencies.ps1" now.

.gitlab-ci.yml build:mingw64: · line 140

Quoted 5 lines

.gitlab-ci.yml +3 -1

   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'

Are we sure that PATH cannot ever contain spaces or should we rather quote here?

Patrick

Johannes Schindelin

2026-09-24 19:55 UTC #8 lore raw

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

Hi Patrick,

Quoted 13 lines · Patrick Steinhardt

.gitlab-ci.yml build:mingw64: · line 136
Quoted 9 lines · Johannes Schindelin via GitGitGadget
.gitlab-ci.yml +1 -0
index cd6fd4a504..3f24835500 100644
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
I wonder whether it would now make sense to also hoist "install-sdk.ps1" into "install-dependencies.ps1" now.

Honestly, I wouldn't. It is conceptually a different thing, the SDK brings a ready-configured environment (which _partially_ ships dependencies, that's right, but it's a Venn diagram, not a strict super set relationship).

Quoted 8 lines

.gitlab-ci.yml build:mingw64: · line 140
Quoted 5 lines
.gitlab-ci.yml +3 -1
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
Are we sure that PATH cannot ever contain spaces or should we rather quote here?

Ah, quoting in shell, what a wonderfully magical world. While you would be correct that passing an unquoted $PATH as an _argument_ would cause unwanted misinterpretation as multiple arguments instead of a single one, _assigning variables_ is a completely different issue. Observe:

  $ x="Patrick Steinhardt"; x=$x=hello env | grep ^x=
  x=Patrick Steinhardt=hello

Wha...? It did _not_ split the $x at whitespace? No. In what must have occurred as quite logical to the inventors of the Unix shell syntax, interpolating unquoted variables in assignments does *not* split at whitespace, unlike in other instances where unquoted variables are very much split at whitespace.

Ciao,
Johannes

Patrick Steinhardt

2026-09-28 06:50 UTC #9 lore raw

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

Quoted 18 lines · Johannes Schindelin

Hi Patrick,
Quoted 13 lines · Patrick Steinhardt
.gitlab-ci.yml build:mingw64: · line 136
Quoted 9 lines · Johannes Schindelin via GitGitGadget
.gitlab-ci.yml +1 -0
index cd6fd4a504..3f24835500 100644
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
I wonder whether it would now make sense to also hoist "install-sdk.ps1" into "install-dependencies.ps1" now.

Quoted 4 lines

Honestly, I wouldn't. It is conceptually a different thing, the SDK brings a ready-configured environment (which _partially_ ships dependencies, that's right, but it's a Venn diagram, not a strict super set relationship).

Fair enough.

Quoted 14 lines

Quoted 8 lines
.gitlab-ci.yml build:mingw64: · line 140
Quoted 5 lines
.gitlab-ci.yml +3 -1
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
Are we sure that PATH cannot ever contain spaces or should we rather quote here?
Ah, quoting in shell, what a wonderfully magical world. While you would be correct that passing an unquoted $PATH as an _argument_ would cause unwanted misinterpretation as multiple arguments instead of a single one, _assigning variables_ is a completely different issue. Observe:

Quoted 8 lines

  $ x="Patrick Steinhardt"; x=$x=hello env | grep ^x=
  x=Patrick Steinhardt=hello
Wha...? It did _not_ split the $x at whitespace? No. In what must have occurred as quite logical to the inventors of the Unix shell syntax, interpolating unquoted variables in assignments does *not* split at whitespace, unlike in other instances where unquoted variables are very much split at whitespace.

Well, TIL :)

Patrick

Junio C Hamano

2026-09-28 14:33 UTC #10 lore raw

Re: [PATCH 3/4] ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

Quoted 4 lines · Patrick Steinhardt

Quoted 3 lines
Quoted 2 lines
Are we sure that PATH cannot ever contain spaces or should we rather quote here?
...
Well, TIL :)

Our coding guidelines share some blame. As some implementations of shells historically were buggy when assignment is combined with modifers (e.g., "export var=val") and split the right hand side at $IFS, we strongly encourage assignment to be written with right hand side quoted even when you shouldn't have to. Uniformly applying the safer rule is easier on mere mortals than knowing and remembering exactly when we do not have to quote and omitting the quote ;-).

Johannes Schindelin via GitGitGadget

author

2026-09-19 12:12 UTC #11 lore raw

PATCH 4/4 ci(gitlab,windows): provide GNU Rust's host-linker support

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>

---
 ci/install-dependencies.ps1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

ci/install-dependencies.ps1 +1 -1

index f6868dc670..9b833b9370 100755
@@ -49,7 +49,7 @@ $rustMsi = Get-Installer "rust-$rustTarget.msi" (
     "https://static.rust-lang.org/dist/" +
     "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
 Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
-    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+    "ADDLOCAL=Rustc,Cargo,Std$(if ($Mingw) { ',Gcc' })", '/quiet', '/norestart')
 
 if ($Mingw) {
     return

Signature · 1 line

gitgitgadget

Patrick Steinhardt

2026-09-24 11:22 UTC #12 lore raw

Re: [PATCH 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

Quoted 10 lines · Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>
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

Hm. Does that mean that we now have two versions of GCC available, once via the MinGW environment and once via Rust?

Thanks!

Patrick

Johannes Schindelin

2026-09-24 19:57 UTC #13 lore raw

Re: [PATCH 4/4] ci(gitlab,windows): provide GNU Rust's host-linker support

Hi Patrick,

Quoted 7 lines · Patrick Steinhardt

Quoted 6 lines · Johannes Schindelin via GitGitGadget
From: Johannes Schindelin <[email protected]>
GitLab's MinGW job cannot find x86_64-w64-mingw32-gcc when linking gitcore's build script:
https://gitlab.com/dscho/git1/-/jobs/16593470275

Quoted 7 lines

Quoted 4 lines
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
Hm. Does that mean that we now have two versions of GCC available, once via the MinGW environment and once via Rust?

I don't think that Rust produces intermediate C by default, so no, this would include a second version of GCC. It will just make sure that the installed Rust version can produce libraries that GCC can link to.

Ciao,
Johannes

Karthik Nayak

2026-09-19 13:37 UTC #14 lore raw

In reply to Johannes Schindelin via GitGitGadget

Quoted 5 lines · Johannes Schindelin via GitGitGadget

In https://lore.kernel.org/git/[email protected]/, 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

Quoted 17 lines

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

Johannes Schindelin

2026-09-20 15:27 UTC #15 lore raw

Hi Karthik,

Quoted 8 lines · Karthik Nayak

Quoted 5 lines · Johannes Schindelin via GitGitGadget
In https://lore.kernel.org/git/[email protected]/, 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).

Quoted 5 lines

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

2026-09-21 14:03 UTC #16 lore raw

Quoted 18 lines · Johannes Schindelin

Hi Karthik,
Quoted 8 lines · Karthik Nayak
Quoted 5 lines · Johannes Schindelin via GitGitGadget
In https://lore.kernel.org/git/[email protected]/, 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).
Quoted 5 lines
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

Quoted 7 lines

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.

Quoted 3 lines

Ciao,
Johannes

Johannes Schindelin

2026-09-22 11:50 UTC #17 lore raw

Hi Karthik,

Quoted 20 lines · Karthik Nayak

Quoted 18 lines · Johannes Schindelin
Quoted 8 lines · Karthik Nayak
Quoted 5 lines · Johannes Schindelin via GitGitGadget
In https://lore.kernel.org/git/[email protected]/, 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).
Quoted 5 lines
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!

Quoted 7 lines

Quoted 5 lines
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

Karthik Nayak

2026-09-23 12:43 UTC #18 lore raw

Quoted 53 lines · Johannes Schindelin

Hi Karthik,
Quoted 20 lines · Karthik Nayak
Quoted 18 lines · Johannes Schindelin
Quoted 8 lines · Karthik Nayak
Quoted 5 lines · Johannes Schindelin via GitGitGadget
In https://lore.kernel.org/git/[email protected]/, 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).
Quoted 5 lines
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!
Quoted 7 lines
Quoted 5 lines
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.

Quoted 3 lines

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

I have no idea about this, but have forwarded the message to the appropriate team. Hopefully we see some resolution. Thanks for the debugging!

Karthik

Quoted 2 lines

Ciao,
Johannes

Johannes Schindelin via GitGitGadget

author

2026-09-24 20:01 UTC #19 lore raw

v2 cover gitlab-ci: fix the cargo invocation in the Windows job

In reply to Johannes Schindelin via GitGitGadget

Changes since v1:

* Reworded the commit messages to clarify previously confusing statements.

 .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-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2233/dscho/fix-cargo-in-windows-gitlab-ci-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/2233

Range-diff vs v1:

1: 6a389b2bad ! 1: cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
@@ Metadata
## Commit message ##
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

- 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.
+ The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
+ Makefile build needs the Rust toolchain that targets GCC (as opposed to
+ the more common MSVC one), not another Git installation or Meson.

- Let the dependency installer serve this configuration while keeping
- the existing package set for MSVC builds.
+ Prepare the install-dependencies.ps1 script to be able to install the
+ GCC-targeting Rust toolchain.

Assisted-by GPT-6

Signed-off-by Johannes Schindelin <[email protected]>

 2:  8855c25128 = 2:  19a4d93181 ci(gitlab,windows): preserve exclusions during dependency setup
 3:  57a83d15fd = 3:  6703fa0349 ci(gitlab,windows): fix Rust setup for GitLab's MinGW build
 4:  1ed79f00cf ! 4:  5310afcdf9 ci(gitlab,windows): provide GNU Rust's host-linker support

@@ Commit message
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
+ as a host executable. We omitted the Rust 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

Signature · 1 line

gitgitgadget

Johannes Schindelin via GitGitGadget

author

2026-09-24 20:01 UTC #20 lore raw

PATCH v2 1/4 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

From: Johannes Schindelin <[email protected]>

The minimal Git for Windows SDK already supplies Git and GCC. The MinGW Makefile build needs the Rust toolchain that targets GCC (as opposed to the more common MSVC one), not another Git installation or Meson.

Prepare the install-dependencies.ps1 script to be able to install the GCC-targeting Rust toolchain.

Assisted-by GPT-6

Signed-off-by Johannes Schindelin <[email protected]>

---
 ci/install-dependencies.ps1 | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

ci/install-dependencies.ps1 +13 -5

index e3b367fa54..8c68fb0cfc 100755
@@ -1,5 +1,6 @@
 param(
-    [string]$DownloadDirectory = '.dependencies'
+    [string]$DownloadDirectory = '.dependencies',
+    [switch]$Mingw
 )
 
 $ErrorActionPreference = 'Stop'

@@ -41,6 +42,17 @@ function Invoke-Installer {
     }
 }
 
+$rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' }
+$rustMsi = Get-Installer "rust-$rustTarget.msi" (
+    "https://static.rust-lang.org/dist/" +
+    "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
+Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
+    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+
+if ($Mingw) {
+    return
+}
+
 $gitAssetVersion = $GitVersion -replace '\.windows\.\d+$', ''
 $gitInstaller = Get-Installer "Git-Installer.exe" `
     "https://github.com/git-for-windows/git/releases/download/v$GitVersion/PortableGit-$gitAssetVersion-64-bit.7z.exe"

@@ -49,7 +61,3 @@ Invoke-Installer $gitInstaller @('-y', '-o"C:\Program Files\Git"')
 $mesonMsi = Get-Installer "meson.msi" `
     "https://github.com/mesonbuild/meson/releases/download/$MesonVersion/meson-$MesonVersion-64.msi"
 Invoke-Installer msiexec.exe @('/i', $mesonMsi, 'INSTALLDIR=C:\Meson', '/quiet', '/norestart')
-
-$rustMsi = Get-Installer "rust.msi" `
-    "https://static.rust-lang.org/dist/rust-$RustVersion-x86_64-pc-windows-msvc.msi"
-Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust', 'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')

Signature · 1 line

gitgitgadget

Johannes Schindelin via GitGitGadget

author

2026-09-24 20:02 UTC #21 lore raw

PATCH v2 2/4 ci(gitlab,windows): preserve exclusions during dependency setup

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 <[email protected]>

---
 ci/install-dependencies.ps1 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

ci/install-dependencies.ps1 +3 -1

index 8c68fb0cfc..f6868dc670 100755
@@ -12,7 +12,9 @@ $RustVersion = '1.96.0'
 
 New-Item -Path $DownloadDirectory -ItemType Directory -Force | Out-Null
 New-Item -Path .git/info -ItemType Directory -Force | Out-Null
-New-Item -Path .git/info/exclude -ItemType File -Force | Out-Null
+if (-not (Test-Path .git/info/exclude)) {
+    New-Item -Path .git/info/exclude -ItemType File | Out-Null
+}
 Add-Content -Path .git/info/exclude -Value "/$DownloadDirectory"
 
 function Get-Installer {

Signature · 1 line

gitgitgadget

Johannes Schindelin via GitGitGadget

author

2026-09-24 20:02 UTC #22 lore raw

PATCH v2 3/4 ci(gitlab,windows): fix Rust setup for GitLab's MinGW build

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

GitLab's MinGW job fails with "cargo: command not found":
https://gitlab.com/git-scm/git/-/jobs/16576450182

86909a94db5d (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 <[email protected]>

---
 .gitlab-ci.yml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

.gitlab-ci.yml +4 -1

index cd6fd4a504..3f24835500 100644
@@ -133,8 +133,11 @@ build:mingw64:
   before_script:
     - *windows_before_script
     - ./ci/install-sdk.ps1 -directory "git-sdk"
+    - ./ci/install-dependencies.ps1 -Mingw
   script:
-    - git-sdk/usr/bin/bash.exe -l -c 'ci/make-test-artifacts.sh artifacts'
+    # The minimal SDK's profile resets PATH.
+    - git-sdk/usr/bin/bash.exe -l -c
+        'PATH=$PATH:/c/Rust/bin ci/make-test-artifacts.sh artifacts'
   artifacts:
     paths:
       - artifacts

Signature · 1 line

gitgitgadget

Johannes Schindelin via GitGitGadget

author

2026-09-24 20:02 UTC #23 lore raw

PATCH v2 4/4 ci(gitlab,windows): provide GNU Rust's host-linker support

In reply to Johannes Schindelin via GitGitGadget

From: Johannes Schindelin <[email protected]>

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 Rust 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 <[email protected]>

---
 ci/install-dependencies.ps1 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

ci/install-dependencies.ps1 +1 -1

index f6868dc670..9b833b9370 100755
@@ -49,7 +49,7 @@ $rustMsi = Get-Installer "rust-$rustTarget.msi" (
     "https://static.rust-lang.org/dist/" +
     "rust-$RustVersion-x86_64-pc-windows-$rustTarget.msi")
 Invoke-Installer msiexec.exe @('/i', $rustMsi, 'INSTALLDIR=C:\Rust',
-    'ADDLOCAL=Rustc,Cargo,Std', '/quiet', '/norestart')
+    "ADDLOCAL=Rustc,Cargo,Std$(if ($Mingw) { ',Gcc' })", '/quiet', '/norestart')
 
 if ($Mingw) {
     return

Signature · 1 line

gitgitgadget

Patrick Steinhardt

2026-09-28 06:50 UTC #24 lore raw

In reply to Johannes Schindelin via GitGitGadget

Quoted 7 lines · Johannes Schindelin via GitGitGadget

Range-diff vs v1:
1: 6a389b2bad ! 1: cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
@@ Metadata
## Commit message ##
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds

Quoted 6 lines

- 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.
+ The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
+ Makefile build needs the Rust toolchain that targets GCC (as opposed to
+ the more common MSVC one), not another Git installation or Meson.

By the way, are there plans to eventually include Rust as part of the GfW SDK? Just asking out of curiosity.

Overall I'm happy with this version, thanks!

Patrick

Johannes Schindelin

2026-09-28 13:41 UTC #25 lore raw

Hi Patrick,

Quoted 15 lines · Patrick Steinhardt

Quoted 7 lines · Johannes Schindelin via GitGitGadget
Range-diff vs v1:
1: 6a389b2bad ! 1: cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
@@ Metadata
## Commit message ##
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
Quoted 6 lines
- 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.
+ The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
+ Makefile build needs the Rust toolchain that targets GCC (as opposed to
+ the more common MSVC one), not another Git installation or Meson.

Quoted 2 lines

By the way, are there plans to eventually include Rust as part of the GfW SDK? Just asking out of curiosity.

I'm still agonizing over that. There is now this new sha1dc Rust crate I want to integrate (patch series about to land), therefore I need to get going with including Rust in Git for Windows' SDK. But it's not looking so rosy! As described in the PR to include Rust in Git for Windows at
https://github.com/git-for-windows/git-sdk-64/pull/132, the addition comes at the price of roughly 110MB.

Given that git-sdk-x86_75-minimal.tar.zst weighs just under 70MB (see
https://github.com/git-for-windows/git-sdk-64/releases/ci-artifacts), that would more than _double_ its size!

So I'm really torn between including Rust (and having a strict subset of the same setup in CI as is used to build Git for Windows releases) or alternatively stick with the current strategy: Expect the correct Rust toolchain to be installed separately in CI.

On GitHub Actions, Rust is basically already there, and we'd save a 110MB extra download for _ever_ win-* job (of which there are _a lot_ on any given day).

But GitLab runners do not (yet?) come with Rust preinstalled, so... 🤷

Quoted 1 line

Overall I'm happy with this version, thanks!

Thanks!
Johannes

Junio C Hamano

2026-09-28 14:26 UTC #26 lore raw

In reply to Patrick Steinhardt

Quoted 15 lines · Patrick Steinhardt

Quoted 7 lines · Johannes Schindelin via GitGitGadget
Range-diff vs v1:
1: 6a389b2bad ! 1: cdf2eff480 ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
@@ Metadata
## Commit message ##
ci(gitlab,windows): provision GNU Rust for SDK-based MinGW builds
Quoted 6 lines
- 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.
+ The minimal Git for Windows SDK already supplies Git and GCC. The MinGW
+ Makefile build needs the Rust toolchain that targets GCC (as opposed to
+ the more common MSVC one), not another Git installation or Meson.

Quoted 6 lines

By the way, are there plans to eventually include Rust as part of the GfW SDK? Just asking out of curiosity.
Overall I'm happy with this version, thanks!
Patrick

Thanks for writing and reviewing, both of you. Let me mark the topic for 'next'.