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 Windows ARM64 rustup setup to a composite action
The "Install rustup" step was duplicated across two jobs:
`test-fast` and `test-fixtures-windows`, both conditioned on
`windows-11-arm`. There is furthermore the possibility that it may
be added in the future to other jobs (such as if it ends up being
useful to run the MSRV check on `windows-11-arm`).
The duplication was such that it would be easy to wrongly change
one but not the other occurrence. If that were to happen, and tests
passed/failed or otherwise behaved differently due to differences
in their CI environments, then it would create the wrong impression
of being related to whether `GIX_TEST_IGNORE_ARCHIVES` is set.
To decrease unnecessary duplication, and more specifically to avoid
that specific confusion and the wild goose chase that might ensue
from it, this extracts the logic of the "Install rustup" steps,
other than the `if` key checking that we are running on
`windows-11-arm`, to a newly created composite action
`setup-windows-arm-rustup`.
The reason for keeping the operating system check in the calling
jobs is so that it is always immediately clear in the job output
whether the step is meant to have an effect.
Although composite actions often make sense to publish separately
and use across repositories, that is probably not the case here.
This logic does only what we need right now, and does not include
functionality such as respecting a preexisitng `CARGO_HOME`
environment variable or making sure to download `rustup-init.exe`
to a location that would be reasonable for all callers.
(This does *not* also extract the "Upgrade Git for Windows" step to
a composite action. It's not necessary to do so, because the step
only currently appears in one job: the `test-fixtures-windows` job,
conditioned on `windows-11-arm`. It would, in principle, be useful
to extract it nonetheless, because it is cumbersome and also
something we've removed and reintroduced before; so making it a
composite action could make it more reasonable to keep around for
next time it is needed. The problem is that there is a benefit to
upgrading Git for Windows before, rather than after, performing any
nontrivial Git operations, to decrease the likelihood of dangling
subprocesses or otherwise open files preventing the Inno Setup
installer from performing the upgrade. There is also a separate
specific benefit to upgrading it before `actions/checkout` runs, so
that step uses it, thereby effectively validating that it really
works. But extracting the "Upgrade Git for Windows" step to a
composite action that runs before the `actions/checkout` step is
complicated, because the otherwise ideal way to refer to the action
locally with a `./` path couldn't be used, because its code would
not yet have been checked out. There are ways around this, but
their complexity suggests they may not be worthwhile until a
composite action is needed in order to actually decrease logic
duplication. See the experiments in #68 for details.)
0 commit comments