You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
0 commit comments