core icon indicating copy to clipboard operation
core copied to clipboard

'dotnet test --no-restore' performs no op with no failure if packages cannot be loaded

Open spencer-langley opened this issue 3 years ago • 7 comments

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 avatar Apr 29 '22 17:04 spencer-langley

@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 avatar Jun 01 '22 03:06 pi3ch

@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.

spencer-langley avatar Jun 01 '22 20:06 spencer-langley

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 avatar Jun 29 '22 09:06 vasicvuk

@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?

spencer-langley avatar Jul 05 '22 13:07 spencer-langley

It was missing few packages in local store that is why it silently exited.

Some error showing reason will help :)

vasicvuk avatar Jul 06 '22 11:07 vasicvuk

Is this still a valid issue @spencer-langley?

/cc @baronfel

mairaw avatar Feb 26 '24 02:02 mairaw

@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)

nathanojb avatar Apr 11 '24 17:04 nathanojb