Почему проекты компилируются компилятором BullsEye?

У нас установлено покрытие BullsEye на всех агентах TeamCity, и есть ночной сценарий, который включает BullsEye, перестраивает мой проект, запускает модульные тесты, а затем отключает BullsEye. Каталог bin BullsEye не находится на пути к машинам, и мой скрипт добавляет путь перед запуском. (Путь добавляется только как часть сценария только для этого сеанса и не устанавливается постоянно для всей машины).

В последнее время я заметил в журнале сборки TeamCity, что все проекты (обычные, а не только те, которые настроены для запуска покрытия) используют компилятор BullsEye. Вот пример из лога:

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

Кроме того, один из проектов строится очень медленно. В частности, «ResolveProjectReferences» занимает около 20 минут. Я читал в Интернете, что это может произойти из-за того, что включен какой-то анализ. Поэтому я вошел на сервер под пользователем TeamCity и снова выключил BullsEye. Но это не помогло.

Итак, мои вопросы:

  • Это нормально, что компилируется компилятором из папки BullsEye, хотя BullsEye не стоит в машинном пути?
  • Как настроить машину так, чтобы компилятор BullsEye использовался только в сценариях покрытия?
  • Может ли это быть причиной того, что сборка занимает много времени?

Спасибо!


teamcity bullseye
person Dina    schedule 30.03.2014    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Да, предполагается, что используется компилятор из папки Bullseye. Вот как работает инструмент покрытия Bullseye, перехватывая фактический компилятор специальной «инструментальной версией». В конце концов, компилятор Visual Studio называется скрытым.

Если вы уберете шаг, на котором скрипты включают Bullseye (путем вызова 'cov01 -1'), тогда компилятор Bullseye должен просто выполнить сквозную передачу компилятору Visual Studio, и у вас не будет охвата кода.

Я не уверен в вопросе времени.

Ссылка на документацию по VS Bullseye: здесь

person bjornruffians    schedule 22.05.2014

arrow_upward
2
arrow_downward

Обратите внимание, что яблочко включено глобально (через реестр?), поэтому любые сборки, которые выполняются параллельно с вашей сборкой покрытия, окажутся (частично) инструментированными. По этой причине мы запускаем наши сборки покрытия на их собственной машине.

person Steve Carter    schedule 19.01.2015
comment
Ты уверен насчет этого? Мы запускаем сборку через пакетный скрипт, который включает покрытие (cov01 --on). Разве это не относится только к этому пакетному скрипту? - person Dina; 20.01.2015
comment
@dina на самом деле нет. Это глобальное изменение, а не для скрипта или даже для сеанса оболочки/терминала. - person rasjani; 11.12.2020
comment
Я могу подтвердить это. Использование Bullseye в конвейере Gitlab с несколькими одновременными исполнителями — это, как я только что узнал, кошмар. Переменная $covfile также является глобальной, поэтому параллельные исполнители вводят условие гонки, чтобы назвать файл. - person JohnMetta; 24.04.2021