gcovr和jenkins不起作用

Question

我试图使用Jenkins的gcovr来生成代码覆盖率报告，但是没有结果，但是如果我从终端运行它，它就会运行得很好。下面是我通过jenkins执行的命令，以生成相同的内容：

gcovr -r /path/to/sourcefiles --object-directory=/Users/testinganywhere1/pathtogcdafile -x -b -e /Developer 1> html/coverage.xml 2>/tmp/Error.txt

如果我通过终端机运行同样的话，它就能正常工作了！

谢谢你的帮助！

PS:我在主机器上运行jenkins，并指示它在从机上执行作业。

Answer 1

在执行对象目录之前，必须先转到它。

 cd /Users/testinganywhere1/pathtogcdafile;
 gcovr -r /path/to/sourcefiles --object-directory=/Users/testinganywhere1/pathtogcdafile -x -b -e /Developer 1> html/coverage.xml 2>/tmp/Error.txt

Answer 2

对于其他有此问题的人，对我来说，这是在作为Jenkins用户从命令行运行时所设置的路径的不同，而实际上是在Jenkins中运行。

因此，尝试在Jenkins中运行"echo $PATH“，并从命令行手动运行，然后将两者进行比较。

Answer 3

我最近为Jenkins和SonarQube做了这样的竞选。该配置的目的是通过社区CXX插件将数据导入SonarQube，但覆盖文件也可以由Jenkins的Cobertura插件使用。

有问题的部分是使XML报告中的源文件名正确。对于SonarQube，它们应该是相对于“项目根”的，该根是'sonar-project.properties‘所在的地方，或者SonarQube的"runner“是从哪里调用的。在我们的例子中，这与工作区的根不一样。

我们需要的“gcovr”版本是当前的头版本(2017-06-14)，因为发布的3.3版本并不适用于我们。此外，在gcovr的“process_gcov_data”函数确定之后，但在应用过滤之前，我必须对其进行归一化处理。对于我们提取的版本，添加了以下内容，作为第524行：

fname = os.path.normpath (fname);

“‘gcovr”有一个限制，它只能在根目录和对象目录之间的文件夹中找到文件--一维搜索。但是，在gcov数据包含相对文件名规范(如头文件)的情况下，这一行之外的文件可能会出现。我向gcovr提出了一张罚单，转而搜索根的子目录，但我不愿屏住呼吸。

我们对“gcovr”的呼吁是：

cd <project-root> && gcovr         \
    <object-directory>             \
    --root=<project-root>          \
    --xml-pretty                   \
    --exclude-unreachable-branches \
    -o <output-xml>

其中<object-directory>是包含对象文件和覆盖数据的位置，而<project-root>是我们项目的基础。所有这些都是绝对路径，<object-directory>在<project-root>下。

在我们的例子中，源代码--在<project-root>和<object-directory>之间的目录中被测试的位置--尽管我不喜欢这个‘’gcovr‘的限制。

然后，<output-xml>包含Cobertura格式的XML覆盖，其中包含相对于<project-root>的文件。

这些是使用Cobertura插件导入Jenkins的。在我们的例子中，我们使用管道脚本，在“管道语法”页面中，插件作为step片段的子选项出现：

step([
    $class: 'CoberturaPublisher',
    coberturaReportFile: '<output-xml>',
    failNoReports: false,
    failUnhealthy: false,
    failUnstable: false,
    maxNumberOfBuilds: 100
])

您的选项可能会有所不同，我们将该文件指定为通配符。

然后，这个覆盖率出现在Jenkins的项目页面上，它既是一个摘要图，也是一个指向“覆盖率报告”的链接，这个链接似乎是准确的。

XML格式包含一个<source>标记，它列出了Jenkins使用的<project-root>的绝对路径。如果这是相对于工作区的话，这将是更好的选择，但这将是另一天。然后，文件名相对于此<source>位置。

SonarQube插件很麻烦，因为它忽略了<source>标记，并要求文件名只是相对于<project-root> (其中调用了声纳运行程序)。

我现在显示了一个强大的1%的项目覆盖率，我正在使用这个模板-但它的数据路径是重要的，在目前.