Closed
Description
My coverage script does the following:
...
# Run the tests
for testproj in $(ls tests/*.Tests -d | grep -v Integration); do
echo ${testproj};
set +e
time \
dotnet test \
--no-build \
--no-restore \
--filter "TestCategory!=Integration" \
--logger:trx \
-r ${base_dir}/.output/ \
$testproj \
/nowarn:NU1701,NU1603,NU1605 \
/p:CollectCoverage=true \
/p:CoverletOutputFormat=opencover
cname=$(basename $testproj)
cp ${testproj}/coverage.xml ${base_dir}/.output/$cname-coverage.xml
set -e
done
...
This works perfectly well for the most part, but I see the following error randomly in different parts of the output on each run:
...
Total tests: 18. Passed: 18. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 4.4549 Seconds
Results File: /tmp/build/5128ae76/.output/_161d9565-a576-4c2a-7fe5-1bb0ae8a6598_2018-04-04_12_54_05.trx
Calculating coverage result...
/tmp/build/5128ae76/source-code-core/packages/coverlet.msbuild/1.0.3-beta1/build/netstandard2.0/coverlet.msbuild.targets(19,5): error : The process cannot access the file '/tmp/build/5128ae76/source-code-core/tests/Diagnostics.Tests/bin/Debug/netcoreapp2.0/MyAssemblyDependency.dll' because it is being used by another process. [/tmp/build/5128ae76/source-code-core/tests/Diagnostics.Tests/Diagnostics.Tests.csproj]
real 0m6.404s
user 0m2.980s
sys 0m0.280s
cp: cannot stat 'tests/Diagnostics.Tests/coverage.xml': No such file or directory
Any ideas?
Cheers,
Paul
NB: coverlet-1.0.3-beta1 is a build of the current master so as to capture the change from PR #23 and hosted in a local nuget repo.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
tonerdo commentedon Apr 4, 2018
What test framework are you using?
sampwil commentedon Apr 4, 2018
I have encountered the same locking issue but it is consistent. I have xUnit tests running on TeamCity version 2017.2.2. Works on my local machine without an issue after PR #23.
/root/.nuget/packages/coverlet.msbuild/1.0.3-beta/build/netstandard2.0/coverlet.msbuild.targets(19,5): error : The process cannot access the file '/opt/buildagent/work/895704bd6e7179f/src/Server.Tests/bin/Debug/netcoreapp2.1/Pie.Quote.Domain.dll' because it is being used by another process. [/opt/buildagent/work/895704bd6e7179f/src/Server.Tests/Server.Tests.csproj]
pms1969 commentedon Apr 4, 2018
@tonerdo I'm using nunit.
@sampwil Interesting that it's working for you after that PR.
tonerdo commentedon Apr 4, 2018
@sampwil @pms1969 what operating system do you get these errors on?
sampwil commentedon Apr 4, 2018
My Teamcity agent setup is
root@27032d820136:/# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial
FROM jetbrains/teamcity-agent
RUN curl https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.gpg
&& mv microsoft.gpg /etc/apt/trusted.gpg.d/microsoft.gpg
&& sh -c 'echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
&& apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
&& curl -sL https://deb.nodesource.com/setup_8.x | bash -
&& apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF
&& echo "deb http://download.mono-project.com/repo/ubuntu xenial main" | tee /etc/apt/sources.list.d/mono-official.list
&& apt-get update
&& apt-get --assume-yes install dotnet-sdk-2.1.300-preview1-008174 nodejs git apt-transport-https ca-certificates curl software-properties-common mono-devel fsharp
&& npm install npm --global
My local setup is
https://docs.microsoft.com/en-us/windows/wsl/install-win10
With Ubuntu 16.04 LTS
@tonerdo The error occurs on the teamcity setup and not my local setup
pms1969 commentedon Apr 5, 2018
@tonerdo I'm running in a slightly modified microsoft/dotnet container. https://hub.docker.com/r/microsoft/dotnet/ 2.0-sdk. I add in a few other things like sonar-scanner, which requires java, and a bunch of tools, but it's not far off being vanilla.
tonerdo commentedon Apr 6, 2018
The problem is from this line: https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Coverage.cs#L82
I restore the backup of the original uninstrumented module so that if the next run uses the
--no-build
flag coverlet will be dealing with the original modulepms1969 commentedon Apr 9, 2018
A simple exponential retrier? I'm guessing the runtime hasn't finished unloading/garbage collecting/finalising/disposing of the module, but that is only a matter of time. It would obviously need a timeout as you don't want to wait around for some dodgy code to finish cleaning up that may never actually do so. An exponential retrier could start with a 6 milliseconds backoff with say 10 retries that's:
6 -> 12 -> 24 -> 48 -> 96 -> 192 -> 384 -> 758 -> 1536 -> 3072
If it hasn't finished inside what is just over 6 seconds then it's a bust. I'd be super surprised if just sleeping 6 milliseconds wasn't long enough for the clr to take control and finish closing the file in 98% of cases. Given that it's done without the need of a retry in a good number of cases already. I'm guessing it depends on how much disposing/finalising work is required by the code under test.
Might also be handy having a log message stating how many retries were required to complete (say with a --verbose flag).
Happy to have a stab at it if you think this is a reasonable approach.
tonerdo commentedon Apr 9, 2018
@pms1969 by all means take a stab at this. Let's leave out logging for now and just do everything behind the scenes.
pms1969 commentedon Apr 9, 2018
@sampwil would you be able to test that PR and see if you still get the issue. Looks like it worked locally for me, but it's always hard to tell if it has actually resolved in cases like this. I'm having some unrelated other system issues as well, so confirmation from another source would be desirable.
sampwil commentedon Apr 9, 2018
@pms1969 Will do. I will try to put on the schedule for today.