PVS-Studio for C＃を使用したGitLabでのマージ要求の分析

GitLabが好きで、バグが嫌いですか？ソースコードの品質を向上させたいですか？その後、あなたは正しい場所に来ました。今日は、マージ要求をチェックするためにPVS-Studio C＃アナライザーをセットアップする方法を説明します。すべてのユニコーンムードと楽しい読書。



PVS-Studioは、C、C ++、C＃、およびJavaで記述されたプログラムのソースコードのエラーと潜在的な脆弱性を検出するためのツールです。Windows、Linux、macOSの64ビットシステムで動作します。32ビット、64ビット、および組み込みARMプラットフォームのコードを分析できます。



ちなみに、PVS-Studio 7.08をリリースしましたが、面白いことがたくさんあります。例えば：

• LinuxおよびmacOS用のC＃アナライザー。
• ライダー用プラグイン;
• ファイルのリストをチェックするための新しいモード。

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

以前は、特定のファイルをチェックするために、ファイルのリストを含む.xmlをパーサーに渡す必要がありました。しかし、あまり便利ではないため、.txtを転送する機能を追加しました。これにより、作業が大幅に簡素化されます。



特定のファイルをチェックするには、-sourceFiles（-f）フラグを指定し、ファイルのリストとともに.txtを渡す必要があります。次のようになります。

pvs-studio-dotnet -t path/to/solution.sln -f fileList.txt -o project.json

コミットまたはプルリクエストのチェックを構成することに関心がある場合は、このモードを使用して構成することもできます。違いは、分析用のファイルのリストを取得することであり、使用しているシステムによって異なります。

マージリクエスト検証の原則

チェックの要点は、アナライザーによって検出された問題が、マージ中にマスターブランチに到達しないことです。また、プロジェクト全体を毎回分析する必要はありません。さらに、ブランチをマージすると、変更されたファイルのリストがあります。したがって、マージ要求のチェックを追加することをお勧めします。



静的アナライザーを実装する前のマージ要求は次のようになります。





つまり、変更ブランチにあったすべてのエラーはマスターブランチに送られます。これは望ましくないので、分析を追加すると、図は次のようになります。





私たちは分析しchanges2をエラーがない場合、我々はそうでない場合、我々はそれを拒否し、マージ要求を受け入れ、そして。



ちなみに、C / C ++のコミットとプルリクエストの分析に興味がある場合は、ここでそれについて読むことができます。

Gitlab

GitLabは、オープンソースのWebベースのDevOpsライフサイクルツールであり、独自のwiki、バグトラッカー、CI / CDパイプラインなどを備えたGitのコードリポジトリ管理システムを提供します。



マージリクエストの分析の実装を開始する前に、プロジェクトを登録してアップロードする必要があります。これを行う方法がわからない場合は、同僚による記事をお勧めします。



注意..。以下に説明する環境設定方法は、その1つです。目標は、分析に必要な環境をセットアップし、アナライザーを実行するための手順を示すことです。おそらく、あなたの場合、環境の準備（リポジトリの追加、アナライザのインス​​トール）と分析の段階を分離する方が最適です。たとえば、必要な環境でDockerイメージを準備して使用する、またはその他の方法です。



これから何が起こるかをよりよく理解するために、次の図を参照することをお勧めします。





アナライザーが機能するには.NETCore SDK 3が必要であるため、アナライザーをインストールする前に、アナライザーに必要な依存関係をインストールするMicrosoftリポジトリーを追加する必要があります。さまざまなLinuxディストリビューション用のMicrosoftリポジトリの追加については、対応するドキュメントで説明されています。



パッケージマネージャを介してPVS-Studioをインストールするには、PVS-Studioリポジトリも追加する必要があります。さまざまなディストリビューションのリポジトリの追加については、ドキュメントの対応するセクションで詳しく説明しています。



アナライザーを操作するには、ライセンスキーが必要です。アナライザーのダウンロードページでトライアルライセンスを取得できます。



注意..。説明されている動作モード（マージ要求の分析）には、エンタープライズライセンスが必要であることに注意してください。したがって、この操作モードを試す場合は、[メッセージ]フィールドにエンタープライズライセンスが必要であることを忘れずに指定してください。



マージ要求が発生した場合は、変更されたファイルのリストのみを分析する必要があります。それ以外の場合は、すべてのファイルを分析します。分析後、ログを必要な形式に変換する必要があります。



これで、作業のアルゴリズムが目の前にあるので、スクリプトの作成に進むことができます。これを行うには、.gitlab-ci.ymlファイルを変更するか、そうでない場合は作成する必要があります。それを作成するには、プロジェクトの名前をクリックする必要があります-> CI / CDを設定します。





これで、スクリプトを作成する準備が整いました。まず、アナライザーをインストールしてライセンスを入力するコードを記述しましょう。

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - 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-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

インストールとアクティブ化は他のすべてのスクリプトの前に行う必要があるため、特別なbefore_scriptラベルを使用します。この断片について少し説明します。



アナライザーのインストールの準備：

  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update

PVS-Studioリポジトリとアナライザーの追加：

  - 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-dotnet

ライセンスのアクティブ化：

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY

$ PVS_NAME-ユーザー名。



$ PVS_KEY-製品キー。



プロジェクトの依存関係を復元します。$ CI_PROJECT_DIRはプロジェクトディレクトリへのフルパスです。

  - dotnet restore "$CI_PROJECT_DIR"/Path/To/Solution.sln

正しく分析するには、プロジェクトを正常にビルドし、その依存関係を復元する必要があります（たとえば、必要なNuGetパッケージをロードする必要があります）。



あなたはをクリックして、ライセンス情報を含む環境変数を設定することができます設定し、その後のCI / CD。





私たちが見つけ、開いたウィンドウで変数項目を、右側に、をクリックして展開し、ボタンや変数を追加します。結果は次のようになります。





これで、分析に進むことができます。まず、完全な分析のためのスクリプトを追加しましょう。フラグ-tはソリューションへのパスを転送し、フラグ-oは分析結果が記録されているファイルの書き込み場所です。リターンコードにも関心があります。この場合、分析中に警告が発行されたという情報がリターンコードに含まれているときに操作が終了することに関心があります。このスニペットは次のようになります。

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

リターンコードはビットマスクのように機能します。たとえば、分析の結果として警告が発行された場合、リターンコードは8になります。ライセンスの有効期限が1か月以内の場合、リターンコードは4になります。分析中にエラーが見つかり、ライセンスの有効期限が1か月以内の場合、コードは4になります。戻り値、両方の値が書き込まれます：数値を合計して、最終的な戻りコード-8 + 4 = 12を取得します。したがって、対応するビットをチェックすることにより、分析中にさまざまな状態に関する情報を取得できます。リターンコードの詳細については、ドキュメント「PVS-Studioを使用したコマンドラインからのVisual Studio / MSBuild / .NETCoreプロジェクトの確認」の「pvs-studio-dotnet（Linux / macOS）リターンコード」セクションを参照してください。



この場合、すべてのリターンコードに関心があります。ここで8が表示されます。

  - exit_code=$((($exit_code & 8)/8))

戻りコードに関心のある数値のビットが含まれている場合は1を取得し、それ以外の場合は0を取得し



ます。マージ要求の解析を追加するときが来ました。これを行う前に、スクリプトの場所を準備しましょう。マージ要求が発生したときにのみ実行する必要があります。次のようになります。

merge:
  script:
  only:
  - merge_requests

スクリプト自体に移りましょう。仮想マシンがオリジン/マスターについて何も知らないという事実に遭遇しました。したがって、私たちは彼女を少し助けます：

  - git fetch origin

次に、ブランチ間の違いを取得して、結果をtxtファイルに保存しましょう。

  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt

ここで、$ CI_COMMIT_SHAは最後のコミットのハッシュです。



次に、-fフラグを使用してファイルのリストの分析を実行します。受信した以前の.txtファイルを転送します。さて、完全な分析との類推によって、リターンコードを見てください：

  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi

マージ要求をチェックするための完全なスクリプトは次のようになります。

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

すべてのスクリプトが実行された後、ログの変換を追加するだけです。after_scriptラベルとplog-converterユーティリティを使用します。

after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

plog-converter ユーティリティは、アナライザのエラーレポートをHTMLなどのさまざまな形式に変換するために使用されるオープンソースプロジェクトです。ユーティリティの詳細については、ドキュメントの対応するセクションのサブセクション「PlogConverterユーティリティ」を参照してください。



ちなみに、IDEからローカルで.jsonレポートを便利に操作したい場合は、IDERider用のプラグインをお勧めします。その使用法については、対応するドキュメントで詳しく説明されています。



便宜上、ここに.gitlab-ci.yml全体を示します。

image: debian

before_script:
  - apt-get update && apt-get -y install wget gnupg 

  - apt-get -y install git
  - wget https://packages.microsoft.com/config/debian/10/
packages-microsoft-prod.deb -O packages-microsoft-prod.deb
  - dpkg -i packages-microsoft-prod.deb
  - apt-get update
  - apt-get install apt-transport-https
  - apt-get update
  
  - 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-dotnet

  - pvs-studio-analyzer credentials $PVS_NAME $PVS_KEY
  - dotnet restore "$CI_PROJECT_DIR"/Test/Test.sln

merge:
  script:
  - git fetch origin
  - git diff --name-only origin/master $CI_COMMIT_SHA > pvs-fl.txt
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -f 
pvs-fl.txt -o PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  only:
  - merge_requests

job:
  script:
  - exit_code=0
  - pvs-studio-dotnet -t "$CI_PROJECT_DIR"/Test/Test.sln -o 
PVS-Studio.json || exit_code=$?
  - exit_code=$((($exit_code & 8)/8))
  - if [[ $exit_code == 1 ]]; then exit 1; else exit 0; fi
  
after_script:
  - plog-converter -t html -o eLog ./PVS-Studio.json

すべてがファイルに追加されたら、[変更のコミット]をクリックします。すべてが正しいことを確認するには、CI / CD- > Pipelines- > Runningに移動します。仮想マシンウィンドウが開き、最後に次のようになります。





Jobが成功したの を見ました-成功、すべてが順調です。これで、行ったことをテストできます。

仕事の例

作業の例として、複数のファイルが存在する単純なプロジェクト（master内）を作成してみましょう。その後、別のブランチで、1つのファイルのみを変更し、マージ要求を作成しようとします。



変更されたファイルにエラーが含まれている場合と含まれていない場合の2つのケースを考えてみます。まず、エラーのある例。



マスターブランチにエラーを含まないProgram.csファイルがあり、別のブランチで、開発者がエラーのあるコードを追加し、マージ要求を作成したいとします。彼がどのような間違いを犯したかはそれほど重要ではありません。主なことはそれが存在するということです。たとえば、私はスロー演算子を忘れました（はい、彼らはとても間違っています）：

void MyAwesomeMethod(String name)
{
  if (name == null)
    new ArgumentNullException(....);
  // do something
  ....
}

エラーのある例を分析した結果を見てみましょう。また、1つのファイルのみが解析されるようにするために、pvs-studio-dotnet起動行に-rフラグを追加しました。





アナライザーがエラーを検出し、ブランチのマージを許可しなかったことがわかります。



エラーなしで例を確認します。コードの修正：

void MyAwesomeMethod(String name)
{
  if (name == null)
    throw new ArgumentNullException(....);
  // do something
  ....
}

マージ要求分析の結果：





ご覧のとおり、エラーは検出されず、タスクの実行は成功しました。これを確認したいと思います。

結論

ブランチをマージする前に不良コードを除外することは非常に便利で楽しいです。したがって、CI / CDを使用している場合は、テスト用に静的アナライザーを組み込んでみてください。さらに、これは非常に簡単に行われます。



清聴ありがとうございました。

この記事を英語を話す聴衆と共有したい場合は、翻訳リンクNikolayMironovを使用してください。PVS-Studio for C＃を使用したGitLabでのマージ要求の分析。