Hi Dscho
On 19/12/2022 14:50, Johannes Schindelin via GitGitGadget wrote:
From: Johannes Schindelin <johannes.schindelin@xxxxxx>
[...]
This developer's initial hope was that it would be enough to fix win+VS
failures and provide the changes to be squashed into contributors'
patches, and that it would be worth the benefit of attracting
Windows-based developers' contributions.
Neither of these hopes have panned out.
I'm sad that those hopes have not panned out, but I think this patch is
probably the best way forward. It is certainly the lowest effort for
non-windows developers and the improvement it CI minutes is very welcome.
Best Wishes
Phillip
To lower the frustration, and incidentally benefit from using way less
build minutes, let's just not run the win+VS jobs by default, which
appears to be the consensus of the mail thread leading up to
https://lore.kernel.org/git/xmqqk0311blt.fsf@gitster.g/
Since the Git for Windows project still needs to at least try to attract
more of said Windows-based developers, let's keep the jobs, but disable
them everywhere except in Git for Windows' fork. This will help because
Git for Windows' branch thicket is "continuously rebased" via automation
to the `shears/maint`, `shears/main`, `shears/next` and `shears/seen`
branches at https://github.com/git-for-windows/git. That way, the Git
for Windows project will still be notified early on about potential
breakages, but the Git project won't be burdened with fixing them
anymore, which seems to be the best compromise we can get on this issue.
Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
---
Explicitly make CMake-based CI failures the responsibility of "Windows
folks"
Ævar and I have brain-stormed off-list what would be the best way to
resolve the mounting frustration with CI failures that are caused by
needing to mirror Makefile changes into the CMake-based build, a burden
that the Git project never wanted to bear.
While he still wants to improve the CMake support (which will benefit
Git for Windows), the main driver of trying to extend CMake support to
Linux (which does not need it because make works very well there,
indeed) was said frustration with CI failures.
A much quicker method to reduce that friction to close to nil is to
simply disable the win+VS jobs, which is what this proposal is about.
(Almost, at least, we still want to keep those job definitions and run
them in Git for Windows' fork to ensure that CMake-based builds still
work.)
A very welcome side effect is to reduce the CI build time again, which
became alarmingly long as of recent, causing friction on its own.
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1445%2Fdscho%2Fonly-run-win%2BVS-in-the-git-for-windows-fork-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1445/dscho/only-run-win+VS-in-the-git-for-windows-fork-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1445
.github/workflows/main.yml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
index e67847a682c..8af3c67f605 100644
--- a/.github/workflows/main.yml
+++ b/.github/workflows/main.yml
@@ -132,7 +132,7 @@ jobs:
vs-build:
name: win+VS build
needs: ci-config
- if: needs.ci-config.outputs.enabled == 'yes'
+ if: github.event.repository.owner.login == 'git-for-windows' && needs.ci-config.outputs.enabled == 'yes'
env:
NO_PERL: 1
GIT_CONFIG_PARAMETERS: "'user.name=CI' 'user.email=ci@git'"
base-commit: c48035d29b4e524aed3a32f0403676f0d9128863
