'dotnet test --no-restore' performs no op with no failure if packages cannot be loaded
Description
Testing a project that uses Nuget, after performing a build, including package restore, attempt to run tests in a new context with no network access (this is to ensure unit tests are not calling external services). If running in a context where nuget sources all require network access then an execution of 'dotnet test --no-restore' or 'dotnet test --no-build' exits immediately with no output and no error code. Running in a CI context this is interpreted as a successful test run when in fact no tests passed.
Note that checking Nuget is not necessary in this situation - the package dlls are already in the build output directory of the test runner and projects under test.
To reproduce: Create solution with a project and a test project with only one nuget package source which is over the network Restore and build project with connectivity to the network Remove network connectivity run 'dotnet test --no-restore' or 'dotnet test --no-build' in the directory of the test project
Configuration
.NET 6 Windows 10 x64
Regression?
Don't know if this ever worked differently
Other information
Believe that even when told not to restore packages or build the cli is doing some linking check before attempting to run and that when this fails it exits without an error. Work around by temporarily adding a file system Nuget source
@spencer-langley to get more verbose output on what is failing try running docker build --no-restore and see if dependencies are missing.
In my case, running build or test under non-root user cased the same scenario as yours. Workaround was to copy over .dotnet and .nuget from /root to the new dotnet home path DOTNET_CLI_HOME and set the right permission for non-root user to write.
@pi3ch Interesting - already have a work around by temporarily adding a local nuget restore source, but I hadn't considered the admin permissions angle. Either way the real issue here is that dotnet test --no-restore fails SILENTLY, which is potentially disastrous behavior for a test runner in a CI context.
We are running tests with mcr.microsoft.com/dotnet/sdk:6.0 container image. And it just silently exists when specifying --no-restore. In general, the user has a root privilege and access to DOTNET_CLI_HOME but still, nothing happens.
I also tried a local NuGet source but that didn't work also. Any idea how to workaround around it?
@vasicvuk if the local nuget source isn't working for you, no. I suspect if the cli is unable to connect to any package source it exits. Are you sure your local package source is correctly configured?
It was missing few packages in local store that is why it silently exited.
Some error showing reason will help :)
Is this still a valid issue @spencer-langley?
/cc @baronfel
@mairaw I can confirm this is still a thing, as I've spent most of today trying to identifying why some broken tests were not causing a failed build. (Using NET8)