web-dev-qa-db-ja.com

Coberturaを使用してJenkinsのソースコードでコードカバレッジを表示（他のマシンからの実行結果）

バックグラウンド

複雑なディレクトリ構造を持つ大規模なc ++アプリケーションがあります。構造が非常に深いため、コードリポジトリをJenkinsワークスペースに格納できませんが、一部のルートディレクトリです。それ以外の場合は、パスの長さ制限が無効になるため、ビルドが失敗します。

アプリケーションはさまざまな環境でテストされるため、テストアプリケーションは別のマシンで実行されます。アプリケーションとすべてのリソースが圧縮され、OpenCppCoverageを使用してテストが実行されるテストマシンにコピーされ、結果としてCobertura xmlが生成されます。

Covarageの結果を表示するにはソースコードが必要なため、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からの2番目の弾丸は完全に混乱しています：

Coberturaはソースコードを見つけましたが、ソースコードを見つけるのに十分な情報を提供しませんでした。

他に何を試しましたか

  1. （アクセスに関する問題を回避するために）誰でもソースコードを読めるようにしました
  2. filenameに相対パスが含まれるようにxmlを変更しました：jenkinsワークスペース、コベリティレポートを含むxmlファイルが配置されているパス
  3. 私のソースコードをさまざまな場所にコピーしました。「cobertura」ディレクトリも含まれています プラグインのソースコードで見つけたこのようなもの
  4. ソースコードを調べて問題を理解しようとしました。
  5. 私はいくつか（少し古い）を見つけました githubプロジェクト これは修正のヒントかもしれません-現在私はそれが正確に何をしているのかを理解しようとしています（このプロジェクトを自分にインポートしたくありません）ビルド構造）。

これまでのところ運はありません。

更新：

突然（私は何をしたのか分かりません）、私のアカウントでうまくいきました。問題は、他のすべてのユーザーが同じ問題を抱えている私に対してのみ機能することです。これは、問題がセキュリティである必要があることを明確に示しています。

c++jenkinscode-coveragecobertura
5
Marek R

わかりました、このプラグインで問題が発生した理由を見つけました。

  1. openCppCoverageのxmlは正解です。これを機能させるためにここで変更する必要はありません（ソースがpdbファイルが指す場所にある限り）。 Jenkinsワークスペース外のソースは、ここでは問題になりません。ビルドマシンからテストマシンに実行可能ファイルをコピーした後、openCppCoverageを使用してテストを実行し、結果をビルドマシンにコピーして戻しました。

  2. ジョブ構成では、コードカバレッジを表示することになっているすべてのユーザーが、セキュリティセクションのJob/workspaceにアクセスできる必要があります。私の場合、ログインしているすべてのユーザーに対してこれを有効にしました。 enter image description here これは、エラーメッセージの最後の箇条書きをカバーしています。

  3. 最も重要なこと：ビルドは成功する必要があります。最初から最後まで形を意味します。 Coberturaプラグインへの呼び出しを含むステップが成功したかどうかを測定しません。いずれかのステップ（将来のステップであっても）が失敗した場合、coberturaはこのカバレッジ実行のコードを表示しません。私の場合、テストの1つがタイムアウトしたため、ビルドジョブが失敗しました。これはopenCppCoverageオーバーヘッドが原因で発生し、係数3によってテストが遅くなります。スクリプトでタイムアウトが検出され、テストの1つが強制終了されました。

ビルドの成功が偶然の問題であることを発見しました。実験中に、coberturaがソースコードを表示した2つのケースに気づきました。

  • ジョブを再実行し、すべてのステップを削除しましたが、coloraturaの結果の公開を担当します。
  • 合格した単一のテストケースを実行するように、ジョブ全体を実行します

ビルドが成功しない場合にカバレッジをまかないことは妥当です（テストが失敗した場合、おそらくコードの誤った分岐が行われた可能性があります）が、UIはそれを別の方法で示す必要があります。

結論

これは、エラーの原因とその詳細をユーザーに正確に報告することが重要な例です。エラーメッセージのどの箇条書きが実際に私のケースなのか、実際には何が問題なのかを理解するために、少なくとも全体の弱さを無駄にしました。実際、プラグインからのエラーメッセージは、コードが表示されないすべての理由を網羅しているわけではありません。

プラグインは何がうまくいかなかったのかをよりよく説明するべきだという報告を提出します。

1
Marek R