[Test PR] Check compatibility with latest Git for Windows#118
Draft
EliahKagan wants to merge 5 commits intomainfrom
Draft
[Test PR] Check compatibility with latest Git for Windows#118EliahKagan wants to merge 5 commits intomainfrom
EliahKagan wants to merge 5 commits intomainfrom
Conversation
EliahKagan
force-pushed
the
run-ci/gfw
branch
from
a873f07 to
7da1599
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
2 times, most recently
from
0b8e70c to
60eadfe
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
from
60eadfe to
9b55519
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
4 times, most recently
from
469753b to
cd77c6d
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
2 times, most recently
from
f3117e1 to
83ca854
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
3 times, most recently
from
6e62719 to
38a2189
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
3 times, most recently
from
6007ec3 to
ee92cf7
Compare
EliahKagan
force-pushed
the
run-ci/gfw
branch
3 times, most recently
from
b7c5e28 to
48a9447
Compare
Upgrading Git for Windows is not usually needed at all. The idea here is to test `winget` to see if it can do it more simply than the code that has been added and removed multiple times before that downloads the installer from the GitHub release and runs it, passing a number of non-obvious InnoSetup arguments. If this works, then it could be a one-liner, but we would still not want to do it by default, and also it may be that not all runners will have `winget` installed or that not all runners will have `winget` set up in a usable way. This applies only to Windows, of course.
So far this only attempts to upgrade it for `test-fast` because whatever is going to go wrong may as well be fixed for that before extending it to `test-fixtures-windows`. The approach followed here is similar to what was done in the past, but some specific details differ, including trying to make it work for both ARM64 and x64 systems and putting everything in a single step rather than three steps.
GitHub Actions has recently started supporting YAML anchors: - https://github.blog/changelog/2025-09-18-actions-yaml-anchors-and-non-public-workflow-templates/ - https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations#yaml-anchors-and-aliases This uses that to have the same step in two separate job definitions without duplicating the code itself. It would often be preferable do put the job in a composite action, but as noted in previous commit messages (especially in the parenthesized paragraph at the end of 9e4e3ec), this job is best run before `actions/checkout`, yet retrieving the action definition from the current repository at the same ref (in a way that is not excessively complicated or slow) requires that `actions/checkout` have been used first. So this uses a YAML anchor instead.
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.
This relates to GitoxideLabs#2221.
There have been multiple incompatibilities before where we needed to change something, usually in the test suite itself, so this experiement checks ahead of time, so we're not rushed.
I first tried to do this with
wingetbut it was not successful, nor am I sure it would always get the latest version once published even if it did work properly. So I went back to the approach that has been added and removed upstream multiple times before, but I put it into a single step and used a YAML anchor to duplicate that step across jobs. See commit messages for details, including what was attempted withwingetand why a YAML anchor is preferable in this specific case to extracting to a composite action.The changes in this fork-internal PR are not meant to be merged anywhere in their current form, because we shouldn't default to upgrading or otherwise changing the version of Git for Windows to something other than what a runner provides. Nor should we test both this and the runner version of Git for Windows in every
pushorpull_requestevent, since that would incur significant delays.But something like this could be turned off by default and made to be able to be turned on by another
matrixvariable, and also aworkflow-dispatchparameter could be added that could let this be triggered manually. Considerations for that:test-fastortest-fixtures-windowsand not the other (at least based on how things have gone before), so it would be good to be able to easily turn it on for just one.