-
-
Notifications
You must be signed in to change notification settings - Fork 359
Use stable Git for Windows in test-fixtures-windows
#1892
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use stable Git for Windows in test-fixtures-windows
#1892
Conversation
Now that Git for Windows 2.49.0 has a stable release, this changes the upgrade step that was added to `test-fixtures-windows` in 4237e5a (GitoxideLabs#1870), so that it downloads an installer from the release marked as "latest", rather than the release that has the newest tag. The release marked "latest" is usually a stable release in projects that have any stable releases, and in particular it is a stable release in Git for Windows. This is *not* needed to switch from the release candidate to the stable release for 2.49.0. The download logic already in place currently gets the stable release automatically, because it is the newest tag. Nonetheless, there are three reasons to prefer the "latest" tag to get the stable release, now that the stable release is available. In descending order of significance, they are: - We upgrade to work around GitoxideLabs#1849, for which 2.49.0 is preferable to 2.48.1 (which the Windows runner images currently have). Continuing to take the newest tag will eventually take a pre-release for the next version. That would probably work, but it is not currently a goal. There is sometimes a delay between when a stable release of Git for Windows comes out and when the stable runner images are released with it. (Pre-release runner images exist, but they are not run on GitHub-hosted runners.) So even assuming this upgrade step is to be removed once it is no longer needed, it could easily end up remaining long enough for a new Git for Windows pre-release to come out. - An update may potentially be released for an earlier minor version (y in x.y.z), in which case the tag for it would be newer and we would downgrade instead. Now that the release marked "latest" is usable here, we can use it and avoid that. - If we decide to eventually deliberately test pre-releases, the step added in GitoxideLabs#1849 would probably not be usable in that form, because it could take either the next pre-release or a patch to an ealier release per the above points, and also for the separate reason that this CI job is not necessarily where we would want to test that. (As one example, there is currently no CI testing of the Git for Windows SDK, even though supporting it, in general and for running the test suite, is an explicit goal discussed in GitoxideLabs#1758, GitoxideLabs#1761, GitoxideLabs#1862, and GitoxideLabs#1864. If that is added, it may be a more opportune way to test prereleases.)
The `ci.yml` workflow uses 2-space indents, including in scripts written in script steps, but there was one place a 4-space ident was used accidentally.
The actual affected code worked as expected (and as I observed in a previous run in my fork), and both here and in my fork the affected job,
My guess is that it is a rare failure that could sometimes happen and is not related to the change here, because:
I do find it odd, though. I have not seen such a failure before. The failing assertion is: gitoxide/gix-fs/tests/fs/snapshot.rs Lines 29 to 31 in 0bf1d5b
I'll rerun the whole workflow, both here and in my fork, and I'll assume this is okay to merge if is passes and nothing else goes wrong. But I wanted to mention this just in case it could somehow be related (?), and more so in case it is an unrelated rare intermittent failure that we manage to explain or to observe again. Edit: When rerunning the workflow, the same test case has failed, now in the Edit 2: It does not usually fail, but I am repeatedly rerunning the workflow, and I got one more failure, this time in the Edit 3: It can happen on main. I got a failure in Edit 4: Here's another occurrence on main in my fork when rerunning it, this time again on |
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)
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)
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)
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)
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)
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
Although this is (currently, and in the immediately foreseeable future) only used in one place, it's cumbersome and also something that we've removed and reintroduced before. Making it a composite action may make it reasonable to keep it around for next time it is needed. It had previously been removed based on the idea that it wasn't clear what form it would need to be in if needed again. Now that it is needed again, the current form as well as the form that seems most likely for future needs is to install the latest stable release of Git for Windows (rather than a release candidate, hard coded version, etc.). Note that this should still not be used habitually, as the Git for Windows installation that ships preinstalled on a runner image should be preferred except when insufficient. See GitoxideLabs#1870, GitoxideLabs#1892, GitoxideLabs#1920, and the recent commit that reintroduced this logic, for background.
Although this is -- currently, and in the immediately foreseeable future -- only used in one place, it's cumbersome and also something that we've removed and reintroduced before. Making it a composite action may make it reasonable to keep it around for next time it is needed. It had previously been removed based on the idea that it wasn't clear what form it would need to be in if needed again. Now that it is needed again, the current form as well as the form that seems most likely for future needs is to install the latest stable release of Git for Windows -- rather than a release candidate, hard coded version, etc. Note that this should still not be used habitually, as the Git for Windows installation that ships preinstalled on a runner image should be preferred except when insufficient. See GitoxideLabs#1870, GitoxideLabs#1892, GitoxideLabs#1920, and the recent commit that reintroduced this logic, for background. This may be a bit complicated to get working, because we want to run the composite action before we have used `actions/checkout`. This is so `actions/checkout` can use and therefore verify that the new Git for Windows version works, and so we don't leave any dangling subprocesses or otherwise open files that would keep the new Git for Windows's Inno Setup installer from removing or replacing the old Git for Windows. But to run a composite action from a`./` path, one ordinarily needs to have checked out the repository already. A composite action can of course be run from a specified ref on a specified repository. But unless we're actually spinning it out to be a general reusable action that versions separately from workflows here such as `ci.yml`, we would always want to run the composite action as defined at the same commit we are at. (The effect of modifying it on a feature branch is othewise cumbersome and unintuitive.) This same commit is often pointed to by the same remote ref -- but not always, because the `pull_request` trigger runs workflows on a temporary merge commit.
Extract "Upgrade Git for Windows" to a composite action Although this is -- currently, and in the immediately foreseeable future -- only used in one place, it's cumbersome and also something that we've removed and reintroduced before. Making it a composite action may make it reasonable to keep it around for next time it is needed. It had previously been removed based on the idea that it wasn't clear what form it would need to be in if needed again. Now that it is needed again, the current form as well as the form that seems most likely for future needs is to install the latest stable release of Git for Windows -- rather than a release candidate, hard coded version, etc. Note that this should still not be used habitually, as the Git for Windows installation that ships preinstalled on a runner image should be preferred except when insufficient. See GitoxideLabs#1870, GitoxideLabs#1892, GitoxideLabs#1920, and the recent commit that reintroduced this logic, for background.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
The `windows-11-arm` runner still has Git for Windows 2.48.1. It thus remains affected by GitoxideLabs#1849 (git-for-windows/git#5436) for now. This is responsible for failures seen so far on `windows-11-arm`, other than the failures that appear to be related to performance. This commit restores the pre-GitoxideLabs#1920 logic for upgrading the Git for Windows installation on the runner, but does so *only* in the `windows-11-arm` job, and *not* in the `windows-latest` job. The code is modified to download the ARM64 installer rather than the x86-64 installer. Besides being only done for `windows-11-arm` and installing an ARM64 build, this is the same as the code in GitoxideLabs#1892 (building on GitoxideLabs#1870). It thus attempts to install the latest stable release, but not pre-releases. See 3501e82 (GitoxideLabs#1920) for further background. Especially in view of the preview status of the `windows-11-arm` image, it may be a good idea to inspect and report the status of the Git for Windows installation before and after the upgrade. But this commit does not add such functionality.
Now that Git for Windows 2.49.0 has a stable release, this changes the upgrade step that was added to
test-fixtures-windows
in 4237e5a (#1870), so that it downloads an installer from the release marked as "latest", rather than the release that has the newest tag. The release marked "latest" is usually a stable release in projects that have any stable releases, and in particular it is a stable release in Git for Windows.This is not needed to switch from the release candidate to the stable release for 2.49.0. The download logic already in place currently gets the stable release automatically, because it is the newest tag.
Nonetheless, there are three reasons to prefer the "latest" tag to get the stable release, now that the stable release is available. In descending order of significance, they are:
We upgrade to work around #1849, for which 2.49.0 is preferable to 2.48.1 (which the Windows runner images currently have). Continuing to take the newest tag will eventually take a pre-release for the next version. That would probably work, but it is not currently a goal.
There is sometimes a delay between when a stable release of Git for Windows comes out and when the stable runner images are released with it. (Pre-release runner images exist, but they are not run on GitHub-hosted runners.) So even assuming this upgrade step is to be removed once it is no longer needed, it could easily end up remaining long enough for a new Git for Windows pre-release to come out.
An update may potentially be released for an earlier minor version (y in x.y.z), in which case the tag for it would be newer and we would downgrade instead. Now that the release marked "latest" is usable here, we can use it and avoid that.
If we decide to eventually deliberately test pre-releases, the step added in #1849 would probably not be usable in that form, because it could take either the next pre-release or a patch to an ealier release per the above points, and also for the separate reason that this CI job is not necessarily where we would want to test that.
(As one example, there is currently no CI testing of the Git for Windows SDK, even though supporting it, in general and for running the test suite, is an explicit goal discussed in #1758, #1761, #1862, and #1864. If that is added, it may be a more opportune way to test prereleases.)
This change also makes the logic slightly simpler, since
gh
has automatically chooses the release marked "latest" when no tag is specified (whereas before we had to find the tag in ongh release ...
invocation to then use it in another).