PVS-Studio を使用した Travis CI、Buddy、AppVeyor でのコミットとプル リクエストの分析

Linux および macOS 上の C および C++ 言語用の PVS-Studio アナライザーでは、バージョン 7.04 以降、指定されたファイルのリストをチェックするテスト機会が表示されます。 新しいモードを使用すると、コミットとプル リクエストをチェックするようにアナライザーを構成できます。 この記事では、Travis CI、Buddy、AppVeyor などの一般的な CI (継続的インテグレーション) システムで GitHub プロジェクト ファイル リスト チェックを設定する方法を説明します。

ファイルリストチェックモード

PVSスタジオ は、C、C++、C#、および Java で書かれたプログラムのソース コード内のエラーと潜在的な脆弱性を検出するためのツールです。 Windows、Linux、macOS 上の 64 ビット システムで動作します。

Linux および macOS 版の PVS-Studio 7.04 には、ソース ファイルのリストを確認するモードがあります。 これは、ビルド システムでファイルを生成できるプロジェクトで機能します。 コンパイル_コマンド.json。 アナライザーが指定されたファイルのコンパイルに関する情報を抽出するために必要です。 ビルド システムが、compile_commands.json ファイルの生成をサポートしていない場合は、ユーティリティを使用してそのようなファイルの生成を試みることができます。 くま.

また、ファイルのリストを確認するモードは、コンパイラ実行の strace トレース (pvs-studio-analyzer トレース) と併用できます。 これを行うには、まずプロジェクトの完全なビルドを実行し、それを追跡して、チェック対象のすべてのファイルのコンパイル パラメーターに関する完全な情報をアナライザーが収集する必要があります。

ただし、このオプションには重大な欠点があります。起動するたびにプロジェクト全体の完全なビルド トレースを実行する必要があり、それ自体がクイック コミット チェックの考え方と矛盾します。 または、トレース結果自体をキャッシュする場合、トレース後にソース ファイルの依存関係構造が変更された場合 (たとえば、ソース ファイルの XNUMX つに新しい #include が追加された場合)、その後のアナライザーの起動が不完全になる可能性があります。

したがって、トレース ログを伴うファイル リスト チェック モードを使用してコミットまたはプル リクエストをチェックすることはお勧めしません。 コミットをチェックするときに増分ビルドを実行できる場合は、モードの使用を検討してください。 増分分析.

分析用のソース ファイルのリストはテキスト ファイルに保存され、パラメーターを使用してアナライザーに渡されます。 -S:

pvs-studio-analyzer analyze ... -f build/compile_commands.json -S check-list.txt

このファイルはファイルへの相対パスまたは絶対パスを指定し、新しいファイルはそれぞれ新しい行に置く必要があります。 分析対象のファイル名だけでなく、さまざまなテキストを指定することもできます。 パーサーはこれがファイルではないことを認識し、その行を無視します。 これは、ファイルが手動で指定されている場合にコメントするのに役立ちます。 ただし、コミットやプル リクエストからのファイルなど、ファイルのリストは CI 解析中に生成されることがよくあります。

このモードを使用すると、メインの開発ブランチに入る前に、新しいコードをすばやくテストできるようになります。 検証システムがアナライザーの警告に反応するには、ユーティリティ プログコンバーター フラグが追加されました --警告を示す:

plog-converter ... --indicate-warnings ... -o /path/to/report.tasks ...

このフラグを使用すると、アナライザー レポートに警告がある場合、コンバーターはゼロ以外のコードを返します。 リターン コードを使用すると、プリコミット フック、コミット、またはプル リクエストをブロックし、生成されたアナライザー レポートを画面に表示したり、共有したり、メールで送信したりできます。

注記。 初めてファイルのリストの分析を開始すると、プロジェクト全体が分析されます。 アナライザーは、ヘッダー ファイル上のプロジェクトのソース ファイルの依存関係のファイルを生成する必要があります。 これは、C および C++ ファイルを解析する機能です。 将来的には、依存関係ファイルをキャッシュできるようになり、アナライザーによって自動的に更新されるようになります。 インクリメンタル解析モードを使用する場合よりも、ファイルリスト チェック モードを使用するときにコミットをチェックする利点は、オブジェクト ファイルではなく、そのファイルのみをキャッシュすればよいことです。

プルリクエスト分析の一般原則

プロジェクト全体の分析には時間がかかるため、プロジェクトの一部だけをチェックするのが合理的です。 問題は、新しいファイルを残りのプロジェクト ファイルから分離する必要があることです。

XNUMX つの分岐があるコミット ツリーの例を考えてみましょう。

コミットしたとしましょう A1 すでにチェックされているかなり大量のコードが含まれています。 少し前にコミットからブランチを作成しました A1 そしていくつかのファイルを変更しました。

もちろん後から気づいたんでしょうね A1 さらに XNUMX つのコミットがありましたが、これらは他のブランチのマージでもありました。 マスター。 そして今、その時が来ました ホットフィックス 準備ができて。 したがって、マージのためにプルリクエストが表示されました B3 и A3.

もちろん、マージの結果全体を確認することもできますが、変更されたファイルは数個だけであるため、これは長すぎて不当になります。 したがって、変更されたもののみを分析する方が効率的です。

これを行うには、マスターにマージするブランチの HEAD にあるブランチ間の違いを取得します。

git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

$MERGE_BASE 後で詳しく検討します。 実際には、すべての CI サービスがマージのベースに関する必要な情報を提供するわけではないため、毎回、このデータを取得する新しい方法を考え出す必要があります。 これについては、以下で説明する Web サービスごとに詳しく説明します。

これで、ブランチ間の違い、つまり変更されたファイル名のリストが得られました。 次に、ファイルを与える必要があります .pvs-pr.list (上記の出力をそれにリダイレクトしました) アナライザーに:

pvs-studio-analyzer analyze -j8 
                            -o PVS-Studio.log 
                            -S .pvs-pr.list

分析後、ログ ファイル (PVS-Studio.log) を読み取り可能な形式に変換する必要があります。

plog-converter -t errorfile PVS-Studio.log --cerr -w

このコマンドは、次のエラーをリストします。 stderr (標準エラー出力ストリーム)。

ここでのみ、エラーを表示するだけでなく、アセンブリおよびテストのサービスに問題の存在を通知する必要があります。 このために、コンバータにフラグが追加されました -W (--警告を示す）。 少なくとも XNUMX つのアナライザー警告がある場合、ユーティリティのリターン コード プログコンバーター は 2 に変更され、プル リクエスト ファイルに潜在的なエラーがあることが CI サービスに通知されます。

トラビスCI

設定はファイル形式で行われます .travis.yml。 便宜上、ファイルから呼び出される関数を含む別の bash スクリプトにすべてを置くことをお勧めします。 .travis.yml (bash スクリプト名.sh 関数名).

必要なコードをスクリプトに追加します。 bash, そのため、より多くの機能が得られます。 セクション内 install 次のように書きましょう:

install:
  - bash .travis.sh travis_install

指示がある場合は、ハイフンを削除してスクリプトに移動できます。

ファイルを開いてみましょう .トラヴィス・シュ アナライザーのセットアップを関数に追加します travis_install():

travis_install() {
  wget -q -O - https://files.viva64.com/etc/pubkey.txt 
    | sudo apt-key add -
  sudo wget -O /etc/apt/sources.list.d/viva64.list 
    https://files.viva64.com/etc/viva64.list
  
  sudo apt-get update -qq
  sudo apt-get install -qq pvs-studio 
}

セクションに追加しましょう スクリプト 分析を実行します:

script:
  - bash .travis.sh travis_script

そして bash スクリプトでは次のようになります。

travis_script() {
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

たとえば、CMake ビルドがある場合、このコードはプロジェクトのビルド後に実行する必要があります。

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
}

次のようになります。

travis_script() {
  CMAKE_ARGS="-DCMAKE_EXPORT_COMPILE_COMMANDS=On ${CMAKE_ARGS}"
  cmake $CMAKE_ARGS CMakeLists.txt
  make -j8
  
  pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY
  
  if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then
    git diff --name-only origin/HEAD > .pvs-pr.list
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                -S .pvs-pr.list 
                                --disableLicenseExpirationCheck
  else
    pvs-studio-analyzer analyze -j8 
                                -o PVS-Studio.log 
                                --disableLicenseExpirationCheck
  fi
  
  plog-converter -t errorfile PVS-Studio.log --cerr -w
}

おそらく、指定された環境変数にすでに気づいているでしょう。 $TRAVIS_PULL_REQUEST и $TRAVIS_BRANCH。 Travis CI はそれらを独自に宣言します。

• $TRAVIS_PULL_REQUEST プル リクエスト番号を保存する、または false通常のブランチの場合。
• $TRAVIS_REPO_SLUG プロジェクトリポジトリの名前を格納します。

この関数のアルゴリズム:

Travis CI はリターン コードに応答するため、警告が存在するとサービスにコミットにバグのフラグを付けるように指示されます。

このコード行を詳しく見てみましょう。

git diff --name-only origin/HEAD > .pvs-pr.list

実際、Travis CI はプル リクエストの分析中にブランチを自動的にマージします。

したがって、私たちは分析します A4としない B3→A3。 この機能のため、次のものとの差を計算する必要があります。 A3、これはからの枝のちょうど上部です 起源.

重要な詳細が XNUMX つ残っています。それは、コンパイルされた翻訳単位 (*.c、*.cc、*.cpp など) でのヘッダー ファイルの依存関係のキャッシュです。 アナライザーは、ファイルのリストをチェックするモードでの初回起動時にこれらの依存関係を計算し、それらを .PVS-Studio ディレクトリに保存します。 Travis CI ではフォルダーをキャッシュできるため、ディレクトリ データを保存します。 .PVS-スタジオ/:

cache:
  directories:
    - .PVS-Studio/

このコードをファイルに追加する必要があります .travis.yml。 このディレクトリには、分析後に収集されたさまざまなデータが保存されます。これにより、その後のファイル リスト分析または増分分析の実行が大幅に高速化されます。 これを行わないと、アナライザーは実際に毎回すべてのファイルを分析することになります。

バディ

トラヴィス C.I. のように、 バディ GitHub に保存されているプロジェクトを自動的にビルドしてテストする機能を提供します。 Travis CI とは異なり、Web インターフェイスで設定されるため (bash サポートが利用可能)、プロジェクトに設定ファイルを保存する必要はありません。

まず最初に、ビルドラインに新しいアクションを追加する必要があります。

プロジェクトのビルドに使用されたコンパイラを指定します。 このアクティビティでインストールされている Docker コンテナに注目してください。 たとえば、GCC には特別なコンテナがあります。

次に、PVS-Studio と必要なユーティリティをインストールしましょう。

次の行をエディタに追加します。

apt-get update && apt-get -y install wget gnupg jq

wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add -
wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list

apt-get update && apt-get -y install pvs-studio

次に、「実行」タブ (最初のアイコン) に移動し、対応するエディターのフィールドに次のコードを追加します。

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

if [ "$BUDDY_EXECUTION_PULL_REQUEST_NO" != '' ]; then
  PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

Travs-CI のセクションを読んだことがあれば、このコードにはすでに馴染みがありますが、ここでは新しいステップがあります。

実際のところ、現在分析しているのはマージの結果ではなく、プル リクエストの作成元のブランチの HEAD です。

つまり、条件付きコミット中です B3 との差を得る必要があります A3:

PULL_REQUEST_ID="pulls/$BUDDY_EXECUTION_PULL_REQUEST_NO"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${BUDDY_REPO_SLUG}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`
git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list

決定する A3 GitHub API を使用してみましょう。

https://api.github.com/repos/${USERNAME}/${REPO}/pulls/${PULL_REQUEST_ID}

Buddy から提供された次の変数を使用しました。

• $BUDDY_EXECUTION_PULL_REQEUST_NO - プルリクエスト番号;
• $BUDDY_REPO_SLUG - ユーザー名とリポジトリの組み合わせ (例: max / test)。

次に、下のボタンを使用して変更を保存し、プル リクエスト分析を有効にしましょう。

Travis CI とは異なり、指定する必要はありません。 .pvs-studio Buddy はその後の起動に備えてすべてのファイルを自動的にキャッシュするため、キャッシュに使用されます。 したがって、最後に残っているのは、PVS-Studio のログイン名とパスワードを Buddy に保存することです。 変更を保存したら、パイプラインに戻ります。 変数の設定に進み、PVS-Studio のログインとキーを追加する必要があります。

その後、新しいプル リクエストまたはコミットが出現するとチェックがトリガーされます。 コミットにエラーが含まれている場合、Buddy はプル リクエスト ページでそれを指摘します。

AppVeyor

AppVeyor のセットアップは Buddy と似ています。すべてが Web インターフェイスで行われ、プロジェクト リポジトリに *.yml ファイルを追加する必要がありません。

プロジェクト概要の [設定] タブに移動しましょう。

このページを下にスクロールして、プル リクエストを構築するためのキャッシュ保存を有効にしましょう。

次に、「環境」タブに移動して、ビルドするイメージと必要な環境変数を指定します。

前のセクションを読んだことがあれば、これらの XNUMX つの変数についてよく知っているでしょう- PVS_KEY и PVS_USERNAME。 そうでない場合は、PVS-Studio アナライザーのライセンスを確認する必要があることを思い出させてください。 将来的には、Bash スクリプトでも再び登場する予定です。

以下の同じページで、キャッシュするフォルダーを指定します。

これを行わない場合、いくつかのファイルではなくプロジェクト全体が分析されますが、指定されたファイルに基づいて出力が取得されます。 したがって、正しいディレクトリ名を入力することが重要です。

次に、スクリプトをテストします。 「テスト」タブを開き、「スクリプト」を選択します。

次のコードをこのフォームに貼り付けます。

sudo apt-get update && sudo apt-get -y install jq

wget -q -O - https://files.viva64.com/etc/pubkey.txt 
  | sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list 
  https://files.viva64.com/etc/viva64.list

sudo apt-get update && sudo apt-get -y install pvs-studio

pvs-studio-analyzer credentials $PVS_USERNAME $PVS_KEY

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
    https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
    | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

plog-converter -t errorfile PVS-Studio.log --cerr -w

コードの次の部分を見てみましょう。

PWD=$(pwd -L)
if [ "$APPVEYOR_PULL_REQUEST_NUMBER" != '' ]; then
  PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
  MERGE_BASE=`wget -qO - 
   https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
   | jq -r ".base.ref"`

  git diff --name-only HEAD origin/$MERGE_BASE > .pvs-pr.list
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck 
                              --dump-files --dump-log pvs-dump.log 
                              -S .pvs-pr.list
else
  pvs-studio-analyzer analyze -j8 
                              -o PVS-Studio.log 
                              --disableLicenseExpirationCheck
fi

このデフォルト値を格納する変数に pwd コマンドの値をかなり具体的に割り当てるのは、一見すると奇妙に思えますが、すぐにすべて説明します。

AppVeyor でアナライザーをセットアップしているときに、アナライザーの非常に奇妙な動作に遭遇しました。 一方で、すべてが正しく機能しましたが、分析は開始されませんでした。 /home/appveyor/projects/testcalc/ ディレクトリにいること、そしてアナライザーは /opt/appveyor/build-agent/ にいることを確認するのに多くの時間を費やしました。 その後、$PWD 変数は少し嘘であることに気づきました。 このため、分析を開始する前にその値を手動で更新しました。

そして、以前と同様に、すべてが次のようになります。

次に、次のスニペットを考えてみましょう。

PULL_REQUEST_ID="pulls/$APPVEYOR_PULL_REQUEST_NUMBER"
MERGE_BASE=`wget -qO - 
  https://api.github.com/repos/${APPVEYOR_REPO_NAME}/${PULL_REQUEST_ID} 
  | jq -r ".base.ref"`

その中で、プル リクエストが宣言されているブランチ間の差異を取得します。 このためには、次の環境変数が必要です。

• $APPVEYOR_PULL_REQUEST_NUMBER - プル リクエスト番号。
• $APPVEYOR_REPO_NAME - ユーザー名とプロジェクト リポジトリ。

まとめ

もちろん、考えられるすべての継続的統合サービスを検討したわけではありませんが、それらはすべて非常によく似た作業の詳細を持っています。 キャッシュを除いて、各サービスは独自の「バイク」を作成するため、すべてが常に異なります。

Travis-CI のような場所では、数行のコードとキャッシュが問題なく動作します。 AppVeyor のように、設定でフォルダーを指定するだけで済みます。 ただし、どこかで一意のキーを作成し、キャッシュされたフラグメントを上書きする機会をシステムに与えるようにする必要があります。 したがって、上記で説明されていない継続的インテグレーション サービスでプル リクエスト分析をセットアップする場合は、まずキャッシュに問題が発生しないことを確認してください。

ご清聴ありがとうございました。 何か問題が解決しない場合は、お気軽に下記までご連絡ください。 支える。 アドバイスやお手伝いをさせていただきます。

この記事を英語圏の読者と共有したい場合は、翻訳リンク「Maxim Zvyagintsev」を使用してください。 PVS-Studio を使用した Travis CI、Buddy、AppVeyor でのコミットとプル リクエストの分析.

出所： habr.com