-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
9 tests rely on commands like ln -s
making copies instead of symlinks on Windows
#1443
Comments
ln -s
making copies instead of symlinks on Windowsln -s
et al. making copies instead of symlinks on Windows
ln -s
et al. making copies instead of symlinks on Windowsln -s
making copies instead of symlinks on Windows
Thanks a lot for reporting!
It's true, the intend is for it to actually create a symlink, even on Windows. It was pretty clear that this didn't happen though, so I started to rely on using archives instead. These are also known to not create symlinks on Windows, I think, and it's strange that 9 failing testsI looked into one of the failing tests, In theory, testing with archives should be the same as testing without, and I'd hope that this Testing without archives on WindowsThere is a way to partition tests and only run a subset of them in a deterministic fashion. To keep Windows runtimes in check and not let them pass 25 minutes, one could use this with a controlling script that runs random, non-repeating partitions until the time runs out. The partitioning should help to over time run all tests, instead of running only the first X tests each time. https://nexte.st/docs/ci-features/partitioning/ Maybe this is something you could establish once all tests are fixed. |
I think the reason for these 9 tests failing is that they don't have archives to begin with, so the scripts are always executed and thus affected by |
I'm relieved that the reason--even if not the needed fix--is straightforward.
It seems to me that pre-generated archives actually have an advantage beyond working around known platforms limitations and speeding up test runs: they provide some protection against unknown platform-specific problems that would cause fixtures to generate the wrong thing, especially if the tests are being run fairly regularly both with and without using the committed archives.
I wonder if there is also a way to effectively compare the archives that get generated (though what kinds of variations are correct would differ across tests that use them). |
This will only reliably work on with developer setups, but that seems fair to assume. If this causes problems, it's fine to make it opt-in as well.
I think I forgot to mention that the idea would be to use nextest as runner but without using test archives to force actually executing the scripts to assure they work. Maybe, instead of complicating the thing with partitioning, the job could also be run but setup so nobody has to wait for it. Ideally, failures get communicated by email but otherwise are not blocking. |
Current behavior 😯
Background
As detailed in #1442,
ln -s
in Git Bash (or other MSYS2 environments) in Windows does not ordinarily attempt to create symlinks, but instead copies files. Its default behavior of copying files is independent of whether the current user has the ability to create symlinks, and also independent of thecore.symlinks
Git configuration variable. The behavior is also not directly related to Git's behavior of creating regular files whencore.symlinks
is not set totrue
, because when Git creates a regular file instead of a symlink, that file still represents a symlink in the index and contains its target path, rather than being a copy of the target.ln -s
is used in about 14 of gitoxide's fixture scripts.Although
ln -s
does not typically attempt to create symlinks, it will attempt to do so--and succeed if the user has the ability to create them without UAC elevation--if the default behavior of MSYS2's emulatedsymlink
system call is customized in theMSYS
environment variable. As noted in git-for-windows/git#3122 (comment) and #1442, one way to do this is to setMSYS=winsymlinks:nativestrict
.One should be careful about doing this automatically, because the user may already have it set; like the
CYGWIN
variable that it is based on, it supports a number of options, not all of which relate to symlinks, which can be set together in its value by separating them with spaces (or tabs). Therefore, if in the future gitoxide test fixtures automatically enablewinsymlinks:nativestrict
, they should probably do so in a way that preserves unrelated options in$MSYS
if present. However, such subtleties can usually be ignored in manual testing on a system whereMSYS
is known to be unset.Test failures with
MSYS=winsymlinks:nativestrict
Originally my goal was to find out if any tests documented as failing in #1358 were failing due to
ln -s
or other Unix-style commands (e.g.,tar
to unpack an archive with symlinks) not really creating symlinks, such that they would pass withMSYS=winsymlinks:nativestrict
. It turns out that there was exactly one such test; see #1358 (comment).However, the bigger effect is that there are nine new failures! This is to say that some tests have been depending on
ln -s
, or other commands that would ordinarily create symlinks, not attempting to do so.Failures when using pre-generated archives
Using pre-generated archives by not defining
GIX_TEST_IGNORE_ARCHIVES
, I ran:This produced 9 failures:
See this gist for the full test output of this run. Other than the information in this issue description, that gist contains the most important information relevant to this issue. The next subsection covers the effect of setting both
MSYS
andGIX_TEST_IGNORE_ARCHIVES
, but for the purpose of showing that their effects are mostly independent, so it may be of less interest.Failures when ignoring pre-generated archives
I independently tried it with:
This gave 24 failures:
But most of those failures are those that occur without setting the
MSYS
environment variable and were reported in #1358. The new failures are the tests that failed above withoutGIX_TEST_IGNORE_ARCHIVES
.See this other gist for the full test output from this run without using pre-generated archives.
Not necessarily specific to
ln -s
These results are not necessarily specific to
ln -s
. This does not necessarily produce the same effect as setting the environment variable only forln -s
calls, because the MSYS behavior it is affecting is not specifically the behavior ofln -s
, but rather the behavior of any executable that links tomsys-2.0.dll
and makes use of the POSIXsymlink
call that it emulates. Some more details on this distinction are given in #1442.Note that fully native executables, including
git
, do not link tomsys-2.0.dll
, so whether they attempt to create symlinks is unaffected by theMSYS
environment variable. In the MSYS2 documentation, this is correlated with the "C library" column in this table.Expected behavior 🤔
When
ln -s
creates symbolic links, that should not cause any tests to fail on any system. If other POSIX commands such astar
are also involved in this, the same applies: when such a command ordinarily would create symbolic links but may not always do so on Windows, its ability to do so on Windows should not break the tests.If special-casing is in place to work around the difficulty creating symlinks on Windows by treating their presence as unexpected, then this disparity with other platforms should be eliminated when possible. If not possible, the special-casing should be made more robust, so it does not assume the absence of features that may be present in reasonable configurations on non-broken systems.
If commands such as
ln -s
are used in test fixtures, or invoked by other means in testing, in any situations where they are really not intended to create symbolic links, then either a different command should be used, or the necessary configuration change should be made, such as removing symlink-related options from the value of$MSYS
when present. My guess, however, is that calls toln -s
in gitoxide's test suite are not deliberately intended to copy a file rather than create a symlink.Git behavior
Not applicable.
Steps to reproduce 🕹
Test commands are all shown above. I ran
gix clean -xde
between tests.The Windows 10 system I tested on has "developer mode" enabled, which permits me to create symlinks without UAC elevation; this is important to the results in that it demonstrates that the problem is not the inability of
ln -s
to create symlinks when it tries, but rather that these nine failures seem to be due to it actually creating them.The text was updated successfully, but these errors were encountered: