【问题标题】:Show code coverage with a source code in Jenkins wiht Cobertura (run result from other machine)在 Jenkins 中使用 Cobertura 的源代码显示代码覆盖率(从其他机器运行结果)
【发布时间】:2020-01-21 13:55:29
【问题描述】:

背景

我有一个具有复杂目录结构的大型 c++ 应用程序。结构太深以至于代码库不能存储在 Jenkins 工作空间中,而是某个根目录,否则构建失败,因为路径长度限制被破坏。

现在由于应用程序在不同的环境中进行测试,测试应用程序在不同的机器上运行。应用程序和所有资源都被压缩并复制到使用OpenCppCoverage 运行测试的测试机器上,结果生成了 Cobertura xml。

现在由于需要源代码来显示协变结果,因此将 xml 复制回构建机器,然后馈送到 Jenkins Cobertura 插件。

问题

覆盖率报告仅显示模块或源代码的百分比结果。代码内容不显示,但显示此错误信息:

来源

源代码不可用。一些可能的原因是:

  • 这不是最新版本(为了节省磁盘空间,此插件仅保留最新版本的源代码)。
  • Cobertura 找到了源代码,但没有提供足够的信息来定位源代码。
  • Cobertura 找不到源代码,所以这个插件没有希望找到它。
  • 您没有足够的权限查看此文件。

现在我发现 this SO answear 很有希望:

输出 xml 文件必须与 coverage 位于同一文件夹中 运行,所以:

coverage xml -o coverage.xml

对源文件夹的引用被放入coverage.xml,如果 输出文件被放入另一个文件夹,引用 源文件夹将不正确。

问题是:

  • 我已经在不同的机器上运行了测试(这可以通过修改 xml 路径的脚本来克服)。
  • 我的源代码在构建期间不能位于工作区中
  • Cobertura 插件不接受将 xml 放在源代码的相应目录中。它以这个错误结束:
[Cobertura] Publishing Cobertura coverage report...

FATAL: Unable to find coverage results

java.io.IOException: Expecting Ant GLOB pattern, but saw 'C:/build_coverage/Products/MyMagicProduct/Src/test/*Coverage.xml'. See http://ant.apache.org/manual/Types/fileset.html for syntax

这是 xml 结果的一部分(修改前):

<?xml version="1.0" encoding="utf-8"?>
<coverage line-rate="0.63669186741173223" branch-rate="0" complexity="0" branches-covered="0" branches-valid="0" timestamp="0" lines-covered="122029" lines-valid="191661" version="0">
  <sources>
    <source>c:</source>
    <source>C:</source>
  </sources>
  <packages>
    <package name="C:\jenkins\workspace\MMP_coverage\MyMagicProduct\src\x64\Debug\MMPServer.exe" line-rate="0.63040511358728513" branch-rate="0" complexity="0">
      <classes>
        <class name="AuditHandler.cpp" filename="build_coverage\Products\MyMagicProduct\Src\Common\AuditHandler.cpp" line-rate="0.92682926829268297" branch-rate="0" complexity="0">
          <methods/>
          <lines>
            <line number="18" hits="1"/>
            <line number="19" hits="1"/>
            <line number="23" hits="1"/>
            <line number="25" hits="1"/>
            <line number="27" hits="1"/>
            ....
          </lines>
        </class>
   ....

最大的问题是我不确定 xml 的位置是否真的是一个问题,因为插件不会报告尝试获取/查找相应源代码时遇到的问题的详细信息。来自 Cobertura 的第二个可能解释问题的子弹完全令人困惑:

Cobertura 找到了源代码,但没有提供足够的信息来定位源代码。

我还尝试了什么

  1. 我已确保任何人都可以阅读源代码(以避免访问问题)
  2. 我已经修改了 xml,所以 filename 包含相对于:jenkins 工作区,带有覆盖率报告的 xml 文件所在的路径
  3. 将我的源代码复制到不同的位置,甚至包含“cobertura”目录,因为something like this I've found in plugin source code
  4. 我已尝试通过检查源代码来了解问题。
  5. 我发现了一些(有点旧)github project,这可能是如何修复它的提示 - 目前我正在尝试研究它的确切作用(我不想将此项目导入我的构建结构) .

到目前为止还没有运气。

更新:

突然(我不确定我做了什么)它适用于我的帐户。问题是它只对我有用,所有其他用户都有同样的问题。这清楚地表明该问题必须是证券。

【问题讨论】:

  • 路径长度限制是 windows 的事情,而不是 Jenkins 的事情。您可以使用符号链接制作更短的路径吗?像 mklink src C:\jenkins\workspace\MMP_coverage\MyMagicProduct\src 之类的东西?
  • @Mzzl:是的,我知道这一点。我只需要使用不同的路径(在 Jenkins 工作区之外)来避免这个 Windows 问题。我不确定这是否会破坏 Jenkins 插件的行为。

标签: c++ jenkins code-coverage cobertura


【解决方案1】:

当我必须为一个非常庞大的 C++ 客户端开发 CI 管道时,我遇到了一个非常相似的问题。如果我避免使用Cobertura Plugin 而是使用HTML Publisher Plugin,我会得到最好的结果。我遇到的主要问题也是找到源文件。

  1. OpenCppCoverage结果转换为HTML

这一步很简单。您必须将参数--export_type=html:&lt;outputPath&gt;(参见Commandline-reference)添加到OpenCppCoverage 调用中。

mkdir CodeCoverage
OpenCppCoverage.exe --export_type=html:CodeCoverage <GoogleTest.exe>

上面的命令应该会在&lt;jenkins_workspace&gt;/CodeCoverage/index.html目录中生成一个html文件

  1. 发布 OpenCppCoverage 结果

为此,我们使用上面提到的HTML Publisher PluginreportDir 是在第一步中创建的目录,其中包含我们的 html 文件。它的路径是相对于 Jenkins 工作区的。

    publishHTML target: [
      allowMissing: false,
      alwaysLinkToLastBuild: true,
      keepAll: true,
      reportDir: 'CodeCoverage',
      reportFiles: 'index.html',
      reportName: 'Code Coverage'
      ]

为了确保每个人都可以下载并在本地查看结果,我们将OpenCppCoverage的结果存档:

   archiveArtifacts artifacts: 'CodeCoverage/*.*'

您现在可以在Code Coverage 下的管道侧边栏中看到结果,结果将如下所示:

这是对我有用的解决方案。

我希望这至少会有所帮助。我只能建议不要使用Cobertura Plugin。我浪费了很多时间试图修复它并识别我的来源......

【讨论】:

  • 这是一些解决方案,但不是很方便。如果有图表显示代码覆盖率的改进或回归,那就太好了。
  • 也许 HTML Publisher Plugin 和 Cobertura 的混合可以工作。 Cobertura 用于图表,另一个用于源代码级别。
  • 我已经疯狂的 coloratura 插件正常工作(见其他答案)。 IMO 的主要问题是插件的错误报告。目前,您必须花费大量时间来找出问题的真正原因。
【解决方案2】:

好的,我找到了这个插件出现问题的原因。

  1. 来自openCppCoverage 的xml 是正确的。此处无需进行任何更改即可使其正常工作(就 pdb 文件指向的源而言)。 Jenkins 工作区之外的来源不是这里的问题。当我将可执行文件从构建机器复制到测试机器时,然后使用openCppCoverage 运行测试并将结果复制回构建机器就可以了。

  2. 在作业配置中,任何应该查看代码覆盖率的用户都必须有权访问安全部分中的Job/workspace。就我而言,我已经为所有登录用户启用了此功能。 这涵盖了错误消息的最后一个要点。

  3. 最重要的是:构建必须成功。我的意思是形式从头到尾。如果包含调用 cobertura 插件的步骤成功,则不计量。如果任何步骤(即使在将来的步骤中)失败,则 cobertura 将不会显示此覆盖运行的代码。在我的情况下,构建工作失败了,因为其中一项测试超时。这是由openCppCoverage 开销引起的,它通过因子3 减慢了测试速度。我的脚本正在检测超时并终止其中一项测试。

我偶然发现构建不成功是一个问题。在实验过程中,我注意到 cobertura 展示了源代码的两种情况:

  • 我已重新运行作业并删除了所有步骤,但一个负责发布 coloratura 结果的步骤
  • 我运行整个作业的方式是运行一个通过的测试用例

如果构建不成功,则不播种覆盖是合理的(如果测试失败,则很可能采用了错误的代码分支),但 UI 应该以不同的方式指示。

结论

这是一个很好的例子,向用户报告错误并提供准确的详细信息以及问题所在和原因非常重要。我浪费了至少整个虚弱来弄清楚实际上是什么错误,哪个错误消息的要点实际上是我的情况。事实上,插件的错误信息并没有涵盖所有不显示代码的原因。

我会报告插件应该更好地解释出了什么问题。

【讨论】:

    猜你喜欢
    • 2013-02-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-05-31
    • 1970-01-01
    • 2013-05-28
    • 2017-07-02
    • 1970-01-01
    相关资源
    最近更新 更多