[PATCH v4 0/2] Use Rust in the Windows CI jobs

With v2.55.0, Git requires Rust by default, with an opt-out that is intended
to be dropped in one of the next versions.

Due to the special circumstances in the Windows part of the CI builds, each
Windows build job first downloads a "minimal Git for Windows SDK" that
contains the GCC toolchain required to build and test Git. As a consequence,
brian m. carlson opted out of Rust in Git's CI definition in 32d5b905909e
(Enable Rust by default, 2026-04-09).

So: How could we stop opting out? Notably, Rust is not part of that minimal
Git for Windows SDK, and including it would more than double that payload,
which I consider prohibitive. Yet including Rust in the minimal Git for
Windows SDK is not actually necessary, at least not for the GitHub workflow:
The runners on which this workflow is defined to run come with Rust
pre-installed.

Granted, this Rust installation is configured to target the Windows-native C
compiler, Visual C. To accommodate for the Windows CI job building with GCC,
this patch series adds a step to the workflow that ensures that the needed
Rust bits are installed and configured.

GitLab peeps, I still would love to ask for your help: I haven't been able
to confirm that GitLab's Windows runners come with Rust preinstalled,
https://docs.gitlab.com/ci/runners/hosted_runners/windows/#available-runtimes
did not clarify that for me. Patrick (or anyone else with access to GitLab
CI), could you see whether this patch series builds on
saas-windows-medium-amd64 without need for further changes?

Changes since v3:

 * Now including the "Changes since v2"... (I thought I had edited the PR
   comment, but either I forgot to press the "Update comment" button, or I
   missed one of the many issues I had today with PR comments, caused by
   many a 500).
 * Removed the now-incorrect paragraph from the commit message that still
   talks about --target.
 * Sending my humblest apologies for such a quick succession (but I really
   think that v3 is ready for next).

Changes since v2:

 * Now using CARGO_BUILD_TARGET; Reworded the commit message accordingly.
 * Dropped the now-unnecessary --target option.

Changes since v1:

 * The inconsistency pointed out by Junio, that UCRT64 was once marked as
   using clang and once as using gcc was fixed by clarifying that UCRT64
   uses GCC.

Johannes Schindelin (2):
  rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
  ci(windows): build with Rust

 .github/workflows/main.yml | 24 ++++++++++++++++++++++++
 Makefile                   |  2 +-
 ci/lib.sh                  |  3 ---
 config.mak.uname           | 25 ++++++++++++++++++++++++-
 4 files changed, 49 insertions(+), 5 deletions(-)


base-commit: f4742f3165d096130c39a71feb26374da37620f2
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-2213%2Fdscho%2Fuse-rust-in-windows-ci-builds-v4
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-2213/dscho/use-rust-in-windows-ci-builds-v4
Pull-Request: https://github.com/gitgitgadget/git/pull/2213

Range-diff vs v3:

 1:  b70b001f62 ! 1:  6e8648b21c rust: pick a GCC-compatible Cargo target under MSYS2/MinGW
     @@ Commit message
          not defined in Git for Windows' minimal SDK that Git uses in its CI
          runs.
      
     -    Note that this _still_ requires an explicit `--target` option to be
     -    picked up in the way Git's build process calls cargo.
     -
          Assisted-by: Claude Opus 4.7
          Signed-off-by: Johannes Schindelin [off-list ref]
      
 2:  76469029ff = 2:  f6c2f52fb3 ci(windows): build with Rust

-- 
gitgitgadget