最近、 JenkinsとSonarQubeでこれを実行しました。この構成は、コミュニティ CXX プラグインを介して SonarQube にデータをインポートすることを目的としていましたが、カバレッジ ファイルは、Jenkins の Cobertura プラグインでも使用できます。
問題の部分は、XML レポートでソース ファイル名を正しく取得することでした。SonarQube の場合、これらは「プロジェクト ルート」 (「sonar-project.properties」が配置されている場所、または SonarQube の「ランナー」が呼び出される場所) に対して相対的であることが期待されます。私たちの場合、これはワークスペースのルートと同じではありませんでした。
リリースされた 3.3 バージョンが機能しなかったため、必要な「gcovr」のバージョンは現在の HEAD リビジョン (2017-06-14) でした。さらに、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」のこの制限は好きではありません。
then には、<output-xml>
を基準としたファイルパスを含む Cobertura 形式の XML カバレッジが含まれています<project-root>
。
これらはCobertura Pluginを使用して Jenkins にインポートされます。私たちの場合、パイプライン スクリプトを使用しています。「パイプラインの構文」ページでは、プラグインがstep
スニペットのサブオプションとして表示されます。
step([
$class: 'CoberturaPublisher',
coberturaReportFile: '<output-xml>',
failNoReports: false,
failUnhealthy: false,
failUnstable: false,
maxNumberOfBuilds: 100
])
オプションは異なる場合があり、ファイルはワイルドカードとして指定されます。
カバレッジは、Jenkins 内のプロジェクトのページに、要約グラフと、正確に思われる「カバレッジ レポート」へのリンクの両方として表示されました。
XML 形式には、Jenkins で使用される<source>
の絶対パスをリストするタグが含まれています。<project-root>
これがワークスペースに関連している場合は望ましいですが、それは別の日にします。ファイル名は、この<source>
場所に相対的です。
SonarQube プラグインは、<source>
タグを無視し、ファイル名が単純に<project-root>
(ソナー ランナーが呼び出された場所) に対して相対的である必要があるため、面倒です。
現在、このテンプレートのワークアウトに使用しているプロジェクトで 1% のカバー率を示していますが、現時点で重要なのはデータ パスです...