[5504] NUnit runner not finding any assemblies
TeamCity Version 3.0.1 EAP (build 5504)
The only way I can get the build agent to find my test assemblies is to
configure the sln2005 runner, "Run NUnit/VSTS Unit tests for:" with the
absolute path to the build agent's directory:
C:\TeamCity\buildAgent\work\Server\b6ab525be7f4e8c6\cps.net\cpstest\bin\cpstest.dll
AFAIK, I should just be able to put in cps.net\cpstest\bin\cpstest.dll,
but when I do that, I see this in the build log :
-
Using "NUnitTeamCity" task from assembly
"C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MSBuildLoggers.dll".
Command:
C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher2.0.exe
"cps.net\cpstest\bin\cpstest.dll"
The "NUnitTeamCity" task is using
"JetBrains.BuildServer.NUnitLauncher2.0.exe" from
"C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher2.0.exe".
Failed to locate assembly cps.net\cpstest\bin\cpstest.dll
TeamCity NUnit 2.2 runner with server logging support. Copyright (C)
JetBrains s.r.o. by Eugene Petrenko
Useage:
]]> assembliesToTest(; or space delimited)
"JetBrains.BuildServer.NUnitLauncher2.0.exe" exited with code -1.
sln2005 output:
-
Also, I originally configured the "...tests for:" like so
"cps.net\cpstest\bin\*Test.dll" because I have many test assemblies.
When I ran it that way, this is the output in the build log:
-
C:\TeamCity\buildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.NUnitLauncher2.0.exe
The "NUnitTeamCity" task is using
"JetBrains.BuildServer.NUnitLauncher2.0.exe" from "C:\TeamCit...
No Assemblies to test
-
It didn't even pass in my wildcard string to the launcher program.
--
Chris
Please sign in to leave a comment.
Chris Morris wrote:
Should I create a JIRA issue for things like this? Will it get more
attention there than in here?
--
Chris
http://www.jetbrains.net/jira/browse/TW-3353
Chris Morris wrote:
>> Should I create a JIRA issue for things like this? Will it get more
>> attention there than in here?
In case anyone cares - feedback in the JIRA shows this problem will be
fixed in the next EAP and provides a workaround until then.
--
Chris