Conversation
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. |
|
Karthik Nayak wrote on the Git mailing list (how to reply to this email): Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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?
>
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
> Ciao,
> Johannes |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -1,5 +1,6 @@ | |||
| param( | |||
There was a problem hiding this comment.
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):
On Sat, Sep 19, 2026 at 12:12:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> 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?
> 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.
> diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> index e3b367fa54..8c68fb0cfc 100755
> --- a/ci/install-dependencies.ps1
> +++ b/ci/install-dependencies.ps1
> @@ -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"
Okay, so installing Rust is the only thing we will want to do on both
MSVC and MinGW builds.
PatrickThere was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Patrick,
On Thu, 24 Sep 2026, Patrick Steinhardt wrote:
> On Sat, Sep 19, 2026 at 12:12:10PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > 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!
> > 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.
> > diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> > index e3b367fa54..8c68fb0cfc 100755
> > --- a/ci/install-dependencies.ps1
> > +++ b/ci/install-dependencies.ps1
> > @@ -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"
>
> 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
| @@ -11,7 +12,9 @@ $RustVersion = '1.96.0' | |||
|
|
|||
There was a problem hiding this comment.
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):
On Sat, Sep 19, 2026 at 12:12:11PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: 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.
Okay, this confirms that it's indeed the plan to start calling this
script for MinGW builds, too.
> diff --git a/ci/install-dependencies.ps1 b/ci/install-dependencies.ps1
> index 8c68fb0cfc..f6868dc670 100755
> --- a/ci/install-dependencies.ps1
> +++ b/ci/install-dependencies.ps1
> @@ -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
| @@ -133,8 +133,11 @@ build:mingw64: | |||
| before_script: | |||
There was a problem hiding this comment.
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):
On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote:
> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> index cd6fd4a504..3f24835500 100644
> --- a/.gitlab-ci.yml
> +++ b/.gitlab-ci.yml
> @@ -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.
> 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?
PatrickThere was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Patrick,
On Thu, 24 Sep 2026, Patrick Steinhardt wrote:
> On Sat, Sep 19, 2026 at 12:12:12PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index cd6fd4a504..3f24835500 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -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).
> > 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
|
|
||
| $rustTarget = if ($Mingw) { 'gnu' } else { 'msvc' } | ||
| $rustMsi = Get-Installer "rust-$rustTarget.msi" ( | ||
| "https://static.rust-lang.org/dist/" + |
There was a problem hiding this comment.
Patrick Steinhardt wrote on the Git mailing list (how to reply to this email):
On Sat, Sep 19, 2026 at 12:12:13PM +0000, Johannes Schindelin via GitGitGadget wrote:
> From: 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
Hm. Does that mean that we now have two versions of GCC available, once
via the MinGW environment and once via Rust?
Thanks!
PatrickThere was a problem hiding this comment.
Johannes Schindelin wrote on the Git mailing list (how to reply to this email):
Hi Patrick,
On Thu, 24 Sep 2026, Patrick Steinhardt wrote:
> On Sat, Sep 19, 2026 at 12:12:13PM +0000, Johannes Schindelin via GitGitGadget wrote:
> > From: 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
>
> 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,
JohannesThe 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 <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 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 <johannes.schindelin@gmx.de>
dscho
force-pushed
the
fix-cargo-in-windows-gitlab-ci
branch
from
September 24, 2026 19:59
1ed79f0 to
5310afc
Compare
Member
Author
|
/submit |
|
Submitted as pull.2233.v2.git.1790280113.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
This patch series is no longer integrated into seen. |
|
There was a status update in the "Cooking" section about the branch The Windows GitLab CI job has been updated to provision and use the GNU Rust toolchain for MinGW builds, fixing job failures caused by incomplete Rust setup and missing linker support. Expecting a reroll. cf. <e58bdd38-59df-5fd0-8c80-e9ab9714dd97@gmx.de> cf. <arUH2KM2rHQwhmpf@pks.im> cf. <arUH3Bi26yyVcrOb@pks.im> source: <pull.2233.git.1789819933.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@5e57c8f. |
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).
Changes since v1:
Cc: Patrick Steinhardt ps@pks.im
cc: Karthik Nayak karthik.188@gmail.com