Use runner-provided Git for Windows now that it's 2.49.0 #1920
Conversation
EliahKagan
force-pushed
the
test-fixtures-windows-default
branch
from
f951866 to
c5d3793
Compare
There was a problem hiding this comment.
Although the new runner image is a stable release and it's been a few days, it is apparently not yet in use on the GitHub-hosted runners. When CI runs on this PR, the runner has has Git 2.48.1. The runner image here is 20250309.1.0 while the version with Git 2.49.0 is 20250330.1.1. I think this can probably be kept open until the GitHub-hosted runners use the new image, then merged. (If that doesn't happen soon, then this PR could be closed and reopened later.)
EliahKagan
force-pushed
the
test-fixtures-windows-default
branch
from
c5d3793 to
c206852
Compare
Because GitoxideLabs#1849 (git-for-windows/git#5436) caused some incorrect test failures in `test-fixtures-windows`, we have been upgrading Git for Windows on the runner for that job: - We starting doing that in of 4237e5a (GitoxideLabs#1870). At that time, we upgraded it to the most recent tag, to select the latest release even though it was a release candiate, because Git for Windows 2.49.0 had not yet had a stable release. - Then Git for Windows 2.49.0 got a stable release, and starting in ddef6d3 (GitoxideLabs#1892) we have upgraded to the release marked "latest" (which in Git for Windows is always the latest stable release). More recently, the Windows Server 2022 runner image (which the `windows-latest` label we use currently selects) has upgraded its Git for Windows installation from 2.48.1 to 2.49.0: https://github.com/actions/runner-images/releases/tag/win22%2F20250330.1 It is therefore no longer necessary for the `test-fixtures-windows` job to upgrade Git for Windows on the runner. This removes the step that did that. (Either version of the step could be brought back from the history if ever needed again.) This closes GitoxideLabs#1849, per the plan in: GitoxideLabs#1849 (comment)
EliahKagan
force-pushed
the
test-fixtures-windows-default
branch
from
c206852 to
3501e82
Compare
|
It turns out that what happened is that, due to regressions with Rust and CMake in the image (actions/runner-images#11941), the image was rolled back soon after being deployed (actions/runner-images#11953). Since then, a newer image 20250406.1.1 is being used. I've observed it to use that newer image in all of a number of re-runs here and in my fork. Still, when it first started being used this morning, it was labeled as a pre-release in Edit: I think this further indicates that the upgrade is well in place and can be relied on: actions/runner-images#11953 (comment) |
Closes #1849
Because #1849 (git-for-windows/git#5436) caused some incorrect test failures in
test-fixtures-windows, we have been upgrading Git for Windows on the runner for that job:We starting doing that in of 4237e5a (#1870). At that time, we upgraded it to the most recent tag, to select the latest release even though it was a release candiate, because Git for Windows 2.49.0 had not yet had a stable release.
Then Git for Windows 2.49.0 got a stable release, and starting in ddef6d3 (#1892) we have upgraded to the release marked "latest" (which in Git for Windows is always the latest stable release).
More recently, the Windows Server 2022 runner image (which the
windows-latestlabel we use currently selects) has upgraded its Git for Windows installation from 2.48.1 to 2.49.0: https://github.com/actions/runner-images/releases/tag/win22%2F20250330.1It is therefore no longer necessary for the
test-fixtures-windowsjob to upgrade Git for Windows on the runner. This removes the step that did that. (Either version of the step could be brought back from the history if ever needed again.)This is as planned in #1849 (comment).