Reading a relative path in test code, how to fix context/root hierarchy issue

I have a case where depending on how one reads, forming a relative path in Github Action within test does not seem to resolve to the right path. I do not know if this is some sort of a Docker mounting thing or maybe something else, so thought to at least document this here and also ask if it’s possible to use my preferred idea to solve this case.

The issue is that in test code the path where the test file is located is combined with a relative path to form a new path where the tests read some files that are being used in the tests. The tests work on local computer from both editor (Visual Studio, Windows) and command line (dotnet test).

This arrangement does not seem to work in Github Action. I am not sure about the reason while I have in mind ways to alter the code. I would prefer not to need to alter the code and see if there’s somehow a way to set a working directory or context some other way to make everything work “as-is”.

A pertinent place is to look one run at and see how some test files are enumerated at /github/workspace/test/DotDecentralized.Tests/TestDIDDocuments/deprecated/EBSI/ebsi-did-1.json.

However, when the tests are run, the location, and consequently the root for the hierarch where the relative path to test files are applied is located at /home/runner/work/DotDecentralized/DotDecentralized/test/DotDecentralized.Tests/bin/Release/net5.0/DotDecentralized.Tests.dll, in GA at

So, the tests use a relative path from this to the project director, a few levels down to hierarchy basically, to read the files. The path looks like being System.IO.DirectoryNotFoundException: Could not find a part of the path '/home/runner/work/DotDecentralized/DotDecentralized/test/DotDecentralized.Tests/TestDIDDocuments/current/Generic in the test step (sorry, two link new poster limit). In tests the path is concatenated from the test dll location using ..//..//../TestDIDDocuments//current//. But it appears this is not in the same file hierarchy as the source code that runts the tests.

But this is strange also since if I enumerate files using ls -Rt I receive output such as

did-2 .json

As can be seen, the test reports the dll being in one path but the enumeration of files ending with .json, the files the tests try to load, are in different hierarchy. It likely is possible to copy the file to test output so they’re in the same file hierarchy or maybe use environment variable for the path, set by GA, which then are used in the tests.

But as noted, it would be nice if I didn’t need to chance the code (since this works “naturally” like this without the need to copy files to output directory) but somehow set some variable or context to make this work as-is in GA. Would it be possible?

This might be a problem with mounting. Maybe the process does not have the rights to access files on that path. I don’t know how to test this theory, though. :slight_smile:

I think I solved this. I am not exactly sure what was the problem, but switching from Directory.GetFiles to FileSystemEnumerable seemed to do the trick. I believe in both cases the operations have been case sensitive and there has not been mixed slashes (all ‘/’ as Windows accepts also them). But I’ve solved my problem. I’ll leave this here in case it offers clues to others in similar situation.

1 Like