GCovr не создает корректный отчет

Я хочу настроить свой Jenkins с помощью Cobertura для отслеживания покрытия кода. К сожалению, я не могу создать правильный xml.

Я использую:

предварительная версия gcovr 2.5 (r2774)
Xcode 4.6.1 Версия сборки 4H512

Мой проект правильно генерирует файлы покрытия кода, но отчет, созданный с помощью gcovr, бесполезен.

Команда, которую я использую для создания отчета:

gcovr -r /Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace 
--object-directory /Users/Shared/Jenkins/Home/Library/Developer/Xcode/DerivedData/myProject-aooceqwwovrizceerghqvhflcfty//Build/Intermediates/myProject.build/Development/myProject.build/Objects-normal/x86_64 
--exclude '.*Developer.*' 
--exclude '.*Tests.*' 
--xml

Это создаст мне этот вывод:

<?xml version="1.0" ?>
<!DOCTYPE coverage SYSTEM 'http://cobertura.sourceforge.net/xml/coverage-03.dtd'>
<coverage branch-rate="0.0" line-rate="0.0" timestamp="1364322914" version="gcovr 2.5-prerelease (r2774)">
<sources>
    <source>
        /Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace/Project/myProject/
    </source>
</sources>
<packages/>
</coverage>

Дополнительная информация:

Если я удалю --object-directory и -r, а затем выполню команду из каталога производных данных, будет сгенерирован действительный отчет. Этот отчет можно прочитать из cobertura, но он не может отображать подробную информацию об исходных файлах.

Giuseppe 26.03.2013 источник

comment

Я фактически ушел в отставку за использование gcovr. Я использую набор сценариев оболочки для создания XML. Сначала я запускаю gcov, затем исключаю некоторые строки между специальными комментариями (я использую CoverStory), а затем генерирую XML из первого столбца вывода gcov. На самом деле это очень просто, вы также можете напрямую ссылаться на исходные файлы в своей рабочей области, чтобы вы могли легко просматривать покрытие файлов на jenkins. - Sulthan 26.03.2013

comment

@Sulthan Возможно ли, чтобы вы поделились своими сценариями? Я не могу заставить gcovr работать с файлами, созданными Xcode 5, и я ищу другое решение. Спасибо! - SAE 07.11.2013

Ответы (3)

arrow_upward
3
arrow_downward

При работе с XCode я обнаружил, что использование $WORKSPACE/build в качестве каталога сборки помогает решить эту проблему. Это удерживает каталог Derived Data вне его, а также аккуратно сохраняет мои объектные файлы в каталоге сборки. Это также предотвращает взаимодействие двух сборок друг с другом.

При использовании инструмента сборки Xcode установите SYMROOT на $WORKSPACE/build в конфигурации сборки инструмента. Если вы строите из командной строки, задайте его вручную в командной строке или в среде.

Затем скрипт gcovr, например:

/your/path/to/gcovr -r . --object-directory build/YourApp.build/Coverage-iphonesimulator/YourApp.build/Objects-normal/i386 --xml > build/coverage.xml

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

И, наконец, в конфигурации Cobertura укажите на build/coverage.xml, и вы должны получить аннотированный исходный код при использовании инструмента в Jenkins.

Должен сделать трюк. Я был очень доволен этой конфигурацией на нашей небольшой ферме Mac Mini.

gaige 26.03.2013

comment

Ваше решение интересно, поэтому я попытался применить некоторые изменения. Когда я устанавливаю собственный путь для CONFIGURATION_BUILD_DIR или SYMROOT, xcodebuild создает некоторые файлы внутри указанной папки. Эти файлы представляют собой только информацию о приложении и символах. Каталог объектов по-прежнему находится в разделе «Производные данные». - Giuseppe; 27.03.2013

comment

Используете ли вы плагин xcode или что-то еще для сборки xcode? Если вы не используете плагин xcode, можете ли вы добавить свой скрипт для команды xcodebuild в вопрос? Существует ряд последующих настроек, которые обычно размещают файлы .o по пути, описанному в SYMROOT, но многие из них можно изменить в проекте. - gaige; 27.03.2013

comment

xcodebuild -workspace myProject.xcworkspace -scheme myProject-Development чистая сборка BUILD_DIR=/Users/Shared/Jenkins/Home/jobs/CodeCoverage/workspace/Project/build/ TEST_AFTER_BUILD=YES - Giuseppe; 27.03.2013

comment

Проверьте конфигурацию проекта Xcode. Обычно SYMROOT находится в верхней части всех каталогов BUILD, в первую очередь: BUILT_PRODUCTS_DIR и CONFIGURATION_BUILD_DIR. Все остальное должно течь оттуда. Если вы не можете найти ничего в конфигурации вашего проекта, что выглядит подозрительно, откройте необработанный журнал в Jenkins и посмотрите, можете ли вы установить переменные, которые задаются в процессе сборки, в места, куда вы видите файлы объектов. Это должно дать некоторую подсказку. - gaige; 27.03.2013

comment

Ни BUILT_PRODUCTS_DIR, ни CONFIGURATION_BUILD_DIR не работали для перемещения каталога производных данных. Я нашел рабочее решение, всегда используя абсолютные пути вместо относительного в параметре, который я передаю в xcodebuild. Таким образом, я могу получить полный рабочий отчет для cobertura. Я все еще заинтересован в том, чтобы найти способ иметь статический каталог производных данных для моей работы, это сделает все более надежным. - Giuseppe; 27.03.2013

arrow_upward
1
arrow_downward

Сценарий gcovr python, похоже, не поддерживает сборки из исходного дерева.

Я создал отчет об ошибке здесь https://github.com/gcovr/gcovr/issues/61

NickBroon 14.08.2014

arrow_upward
1
arrow_downward

gcovr следует запускать из папки, в которой находятся файлы .gcda и .gcno. А корневой путь — это папка, в которой существуют исходные файлы (.c или .cpp).

При этом команда выглядит примерно так, как показано ниже.

rr-mac:gcdaFolder$ gcovr -r /path_to_C_sourceFiles/ .

Для выходного html-файла ниже работает команда

rr-mac:gcdaFolder$ gcovr --html -o Filename_rp.html -r /path_to_C_sourceFiles/ .

Примечание. Точка (.) в конце обязательна.

Rajesh Pappireddy 12.08.2016

comment

Что это '.' в конце указать? - David Doria; 24.09.2016

comment

'.' указать текущий каталог - Rajesh Pappireddy; 25.04.2017

GCovr не создает корректный отчет

Ответы (3)

Похожие вопросы