SonarQube (SonarCloud) 対応

[m-tmatma]

#510: SonarQube (SonarCloud) 対応

• SonarQube (SonarCloud) に対応します。
• SonarQube は静的解析ツールで、クラウド対応したものが SonarCloud です。
• GitHub のアカウントでログインすることができます。
• 結果は https://sonarcloud.io/dashboard?id=sakura-editor_sakura で確認できます。
• Azure Pipelines で解析作業を実施します。
• 実行に約 1時間かかるので、PR や branch への push のたびに実行せずに毎日決まった時間 (日本時間 0:00) に実行する設定を行います。
• どのタイミングで実施するかは azure-pipelines.yml の condition の設定で variables['Build.Reason'] の値をもとに限定しています。
• SonarQube.md のドキュメントに手順等記載しています。

[m-tmatma]

タイトル、本文が途中で登録されてしまったので、修正しました。

[m-tmatma]

appveyor 上で実行すると、job の実行時間が 1時間以内という appveyor の制限に引っかかって
ビルドに失敗するので appveyor 上での実行を無効にしています。
ローカルでビルドして、解析結果を SonarCloud 上にアップすることも可能です。

↓ 以下はローカルでビルド、解析した結果を SonarCloud 上にアップしたものです。
https://sonarcloud.io/dashboard?id=sakura-editor_sakura

とりあえず、動かすところまでできたので、
導入するか? という議論のたたき台にするための情報共有が目的です。

[m-tmatma]

いろいろ試行錯誤のコミットがあるので、わかりずらいということであれば
rebase してきれいにします。

また build-sln.bat もこの対応のためのリファクタリングが入っているので
必要であれば、別 PR にすることも可能です。

[m-tmatma]

appveyor 上で実行すると、job の実行時間が 1時間以内という appveyor の制限に引っかかって

appveyor/ci#517
によると 1時間30分までは延長してもらえるみたい。

[m-tmatma]

導入するか? という議論のたたき台にするための情報共有が目的です。

補足: すべてのビルドで実行するのは想定してなくて、多くても一日一回、長くて一週間に一回くらい
実行すればいいかな、と考えています。

[m-tmatma]

appveyor/ci#2818 作成

[berryzplus]

https://sonarcloud.io/dashboard?id=sakura-editor_sakura

よさげ。（ただの感想

[m-tmatma]

対応完了しました。レビューお願いします。

[berryzplus]

ちゃんと動かしてから判断しようと思って動作確認中。

さっきまで curl本家 に繋がらなくてだいぶ焦りました。

[m-tmatma]

さっきまで curl本家 に繋がらなくてだいぶ焦りました。

Git をインストールすると "C:\Program Files\Git\mingw64\bin\curl.exe" にインストールされています。

[m-tmatma]

さっきまで curl本家 に繋がらなくてだいぶ焦りました。

Git をインストールすると "C:\Program Files\Git\mingw64\bin\curl.exe" にインストールされています。

ドキュメントに追加しました。

[berryzplus]

動作確認状況...

• とりあえずローカルで実行することには成功
• 検証用のプロジェクトに結果反映することにも成功
• ソースコード変更したら結果が更新されることを確認
• ビルドプロセスで時間が掛かるのは sonarscanner end の部分だと気付く
• 環境変数経由でjavaスタックサイズを調整できると書いてあった気がする(-mx512m)ので、その設定を弄ったら時間短縮になったりしないだろうか。-mx512mは小さすぎないだろうか。
• Coverageを取ってサマリ表示する機能があることに気付く
• カバレッジ表示するには sonarscanner begin ～ sonarscanner end の間にテストを実行する必要がありそう。現在は build-sln.bat の中で sonarscanner end してるので「これでいいんだっけ？」と考え中。
• vstest.console.exe(visual studioのテスト実行ツール)にはカバレッジを取るモードがあるが、これでカバレッジを取るにはDebugビルドする必要があるらしい。←やるならビルド環境に制限が付く。
• カバレッジを取るには vs2017 Enterprize が必要？どうしてもダメならMinGWビルドにgcov仕込むプランの模索もあると思ってる。ある意味、そういうことするためにgcc環境を残してあるわけで。

[berryzplus]

メモ：SonarScannerの実行要件 https://docs.sonarqube.org/display/SCAN/Install+the+SonarScanner+for+MSBuild

Prerequisites  
To execute analysis with SonarScanner for MSBuild you need to have:
•Java Runtime Environment 8 (JRE 8) on your machine. Also make sure that the $JAVA_HOME environment variable points to the path where JRE 8 is installed.
•a SonarCloud account or a SonarQube server.

Java実行環境は8推奨、JDKでもJREでもいいが、OpenJDKかOracleJDKを使うように、とのこと。

[berryzplus]

スキャナーが遅い件

スキャナーのメモリは、増やしてもあんまり速度変わらんかったです。
この件は諦めます:cry:

カバレッジを取って反映する件

カバレッジ収集に関するマニュアル

• sonar.cxx.coverage.reportPath for unit test coverage

この辺のPRで出てくる googletest の --gtest_output オプションの話が関係してくるんじゃなかろうか。

• googletest の結果を appveyor に反映する際 XML 出力を使う googletest の結果を appveyor に反映する際 XML 出力を使う #735
• [WIP] googletest のテスト結果を azure pipelines で公開する googletest のテスト結果を成功、失敗含めて azure pipelines の Web サイトで確認できるようにする #837

ビルド済みの gmain 利用プログラムを動かす分には、
visual studio の Enterprise Edition 以上が必要、
という制約もパスできるように思います。

PRの評価とは別に、引き続き調査検討をしていきたいと思っています。

このPRのマージに至るまでの残件

問題は、テストのビルドと実行を sonarscaner end の前に持っていく対応を、初期導入から入れるか否かだと思います。

そもそもの話、テストカバレッジを分析対象としたいか否か。

やるための機構があるのだから、ぼくは対象にしたほうがいいと思ってます。
今すぐに導入しても カバレッジ 1%未満 とか表示されて ｼｮﾎﾞｰﾝ になるので、
初期導入では「あえて対応しない」の考え方もアリだと思います。

現時点で SonarQube を使い始めるのに十分な環境が整備されたという判断なんですが、
カバレッジ分析を使えるようにするために大きな変更が要りそう、って点がapprove躊躇の要因になっています。

さて、どうしたもんでしょう。

[m-tmatma]

別に一つの PR で全部やる必要はないと思います。
単体テストはあえてこの PR では対象にはしてません。

PR は可能な限り小さくするのがいいです。

[berryzplus]

初期導入として申し分ない整備状況だと思います。

これでココの情報が日々更新されるようになるという理解です。
https://sonarcloud.io/dashboard?id=sakura-editor_sakura

別に一つの PR で全部やる必要はないと思います。
単体テストはあえてこの PR では対象にはしてません。

PR は可能な限り小さくするのがいいです。

そろそろ理解の許容限界を超えてきそうなので、いったん運用を始めてみましょう。
これもまぁ、問題がなくても変化していく開拓分野ですし。

[m-tmatma]

マージして以下のように定期実行設定したら、 https://dev.azure.com/sakuraeditor/sakura/_build/results?buildId=306 のようにビルドが走った。

[m-tmatma]

以下の設定に戻した。

[berryzplus]

スキャナーが遅い件

スキャナーのメモリは、増やしてもあんまり速度変わらんかったです。
この件は諦めます😢

ローカルでうまくやる方法を見付けたのでとりあえず共有。

@rem to ensure hide variable SONAR_QUBE_TOKEN
@echo off
"%SonarScanner_MSBUILD%" begin                      ^
	/k:"%SONAR_QUBE_PROJECT%"                       ^
	/o:"%SONAR_QUBE_ORG%"                           ^
	/d:sonar.cfamily.build-wrapper-output=%~dp0bw-output ^
	/d:sonar.cfamily.threads=%NUMBER_OF_PROCESSORS%  ^
	/d:sonar.sourceEncoding=UTF-8                   ^
	/d:sonar.host.url="https://sonarcloud.io"       ^
	/d:sonar.login="%SONAR_QUBE_TOKEN%"

同時実行スレッド数 sonar.cfamily.threads がデフォルトでは 1 に設定されている。
ここに環境依存の値（＝利用可能なコア数）を入れてやると解析速度が劇的に改善する。
1スレッドで1時間かかる作業も、4スレッドなら15分で終わる。

Azule Pipelines で %NUMBER_OF_PROCESSORS% がどれくらいかは分かりませんが、リアルに1コアってことはないと思うので、それなりな改善を見込めると思われます。

うちの環境で スレッド数=4 にして実行させて見たログです。

INFO: Analysis total time: 11:51.584 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 11:56.458s
INFO: Final Memory: 34M/1375M
INFO: ------------------------------------------------------------------------
The SonarQube Scanner has finished

利用可能なコア数が8とかだったら10分を切りそうな感じに効果てきめんなので、試してみる価値がありそうです。