git-lfs/.ruby-version
Chris Darroch b7fa3a54e4 .github/workflows: upgrade to ruby/setup-ruby@v1
As the actions/setup-ruby GitHub Action is deprecated in favour of
the ruby/setup-ruby Action, we upgrade to use the latter in our CI and
release workflows.

In the Windows builds, the ruby/setup-ruby@v1 Action installs the MSYS2
build tools and sets some environment variables which persist for
subsequent steps in the workflow, such as the TMPDIR variable.

These differences from the actions/setup-ruby Action introduce failures
into our test suite, principally by causing Actions to run the Bash shell
in C:\msys64\usr\bin instead of the one in C:\Program Files\Git\bin, which
in turn results in the "git" command running the git.exe binary found in
C:\Program Files\Git\bin instead of C:\Program Files\Git\mingw64\bin.

The Git binary in C:\Program Files\Git\bin, when asked to run a "git lfs"
command, then finds the git-lfs.exe binary in C:\Program Files\Git\cmd
instead of the one we have built, despite our changing the PATH
environment variable so that our built git-lfs.exe binary should be
found first.

We resolve this problem by renaming the C:\msys64 directory with a
temporary name after installing the asciidoctor Ruby gem.

Also note that we do not need to specify the Bash shell to run the
"gem install acsiidoctor" step, and that we move this step below the
ruby/setup-ruby@v1 step in all cases so as to make the dependency
more clear.  (We also move the "gem install packagecloud-ruby" step
into the same relative location, for the same reason.)

The ruby/setup-ruby@v1 Action also sets the TMPDIR environment variable
for all subsequent steps, and this results in other test suite failures
on Windows because we create paths for our temporary test repositories
in our GIT_LFS_TEST_DIR path, which we set using mktemp(1), and that
derives its defaut path from TMPDIR.  However, some of our test helper
programs such as lfstest-customadapter use the Go language ioutil.TempFile()
function to construct paths, which calls os.TempDir(), and on Windows
that does not refer to the TMPDIR environment variable but the TMP and
TEMP ones instead.

The consequence is that tests using those helper programs try to
move files between directories creating using both techniques of
temporary path creation, and these return paths on different volumes,
so the test fails when trying to move files between D:\a\_temp
and C:\Users\RUNNER~1\AppData\Local\Temp.

Therefore we take care to unset the TMPDIR variable before running
commands which might make use of mktemp(1).

h/t MSP-Greg for the suggestion to rename C:\msys64
2022-12-21 19:30:13 -08:00

2 lines
6 B
Plaintext