3

We have BullsEye Coverage installed on all the TeamCity agents and there's a nightly script which turns on BullsEye, rebuilds my project, runs unit tests and then turns BullsEye off. The BullsEye bin directory is not in the path of the machines and my script adds the path prior to running. (The path is added only as part of the script for that session only and is not set permanently for the entire machine).

Lately I have noticed in the TeamCity build log that all projects (the regular ones, not just the ones which are configured to run coverage) use the BullsEye compiler. Here's an example from the log:

[11:29:38] [bsii_algorithms\build\vc10\bsii_algorithms.vcxproj] ClCompile (8s)
[11:29:38] [ClCompile] CL (3s)
[11:29:38] [CL] C:\Program Files (x86)\BullseyeCoverage\bin\CL.exe /c /I..\..\include /I..\..\..\bsii_common\include ...

Also, one of the projects builds really slow. Specifically, "ResolveProjectReferences" takes about 20 minutes. I read online that this could happen because some sort of analysis is turned on. So I logged in to the server using the TeamCity user and turned BullsEye off again. But it didn't help.

So my questions are:

  • Is it OK that everything is compiled with the compiler from the BullsEye folder even though BullsEye is not in the machine path?
  • How can I configure the machine so that only the coverage scripts use the BullsEye compiler?
  • Can this be the reason builds are taking a long time?

Thanks!

Dina
  • 1,346
  • 1
  • 15
  • 35

2 Answers2

2

Note that bullseye is turned on globally (through the registry?) so any builds that are running in parallel to your coverage build will find themselves (partially) instrumented. For this reason we run our coverage builds on their own machine.

Steve Carter
  • 475
  • 4
  • 6
  • Are you sure about this? We run the build through a batch script that turns on the coverage (with cov01 --on). Doesn't this apply just for that batch script? – Dina Jan 20 '15 at 17:33
  • @dina it actually does *not*. It is global change, not per script or even per shell / terminal session – rasjani Dec 11 '20 at 13:25
  • I can confirm this. Using Bullseye in a Gitlab pipeline with multiple concurrent runners is, as I've just found out, a nightmare. The $covfile variable is global too, so concurrent runners enter a race condition to name the file. – JohnMetta Apr 23 '21 at 23:13
0

Yes, it's expected that the compiler from the Bullseye folder is used. This is how the Bullseye coverage tool works, by intercepting the actual compiler with a special "instrumented version". Eventually, the Visual Studio compiler is called under-the-hood.

If you remove the step where the scripts enable Bullseye (by calling 'cov01 -1'), then the Bullseye compiler should just do a pass-through to the Visual Studio compiler and you won't have code coverage.

I'm not sure about the timing question.

Link to the VS Bullseye documentation : here

bjornruffians
  • 671
  • 5
  • 16