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
When retesting `gix-path` without `git` being in the `PATH`, this
adds a step to verify that the `EXEPATH` environment variable is
not set. If `EXEPATH` is set, the the `EXEPATH` optimization could
succeed even if the fallback strategy that is intended to be more
reliable would fail due to a regression.
This applies only to the `test-fast` jobs on Windows, where we
rerun `gix-path` tests (to make sure they work even when `git is
not in the path, when Git for Windows is installed in one of the
common locations). In contrast, fine if `EXEPATH` is set (or not)
in the `test-fixtures-windows` jobs.
Although it's possible to run the `gix-path` tests a third time
with `EXEPATH` set, it wouldn't really make sense to do so when
`git` is not found in `PATH`, since the scenarios where `EXEPATH`
is expected to have a usable value are in a Git Bash environment
where `git` will be in the `PATH` even if it is not otherwise.
(It might make sense to test a Git Bash environment explicitly, but
that would still be with `git` in `PATH`, and this does not add
such tests. It can be done later if needed to guard against a
regression, and it will also likely be done eventually if more Git
for Windows installations are tested: Git for Windows SDK, MinGit,
MinGit with Busybox, MinGit 32-bit, and/or Git for Windows running
inside a native Windows container. The absence of tests using a Git
Bash environment should not be confused with tests of interaction
with the Git for Windows provided `bash` shell on Windows. That we
do test: both directly, and indirectly but heavily in fixtures via
`gix-testtools`.)
0 commit comments