前文
しばらく前、コードを整理することにしたので、コードスタイルの制御システムとしてCheckstyleを選択しました。 このプロジェクトは馴染みがあり、導入の必要はないと思います。 その前に、チームでは、コードスタイル、アイデアの意図が保存されている共通のリポジトリを使用しました。
プロジェクトにcheckstyleを追加することにより、まず目標を追求しました-コードスタイルの設計のエラーをアセンブリエラーに変換する機能です。 手首を軽く動かすだけで、checkstyleはプロジェクトのルートポンに接続され、開発者はイノベーションに導入され、Teamcityのビルドはコミットする前にcheckstyleをチェックすることを学びました。
しかし、これは不運です。害虫が私たちのランクに現れました。 私たちは彼とどのように戦ったか-カットの下で。
次のリリースをビルドすると、悪意のある変更がすぐに気付きました。 アセンブリはメッセージで落ちました：
[ERROR] Habr.java[31:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang [ERROR] Habr.java[32:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang
うん、私は今、私はあなたを理解するだろうと思った。 そして、gitの非難を取り上げました。 侵入者はすぐに計算されました。 侵入者が私であることが判明したときの驚きを想像してください。 しかし、結局、コミットの前にプロジェクトをまとめ、チェックスタイルを廃止しました。
当然、「すべてをチェックし、ここに1行追加してください。間違いなく何も壊さない」というカテゴリからの監視でした。 コードが修正され、リリースが再構築され、状況が解決されました。 しかし、翌日、同僚と同じ状況が繰り返されました。 Intelij Ideaには、コミットダイアログで有効にできる優れた「コードの再フォーマット」オプションがあります。 私はすべての同僚に彼女にアドバイスし、この問題を一度忘れてしまいますが、ここでも再び-アセンブリはログに記録されません：
[ERROR] Habr.java[136:27] (whitespace) WhitespaceAround: 'if' is not followed by whitespace.
もちろん、誰かがこのオプションを有効にするのを忘れて、誰かがこの手紙を無視しました。 しかし、会話の最初に戻ります-チェックスタイルを使用してコードの設計のエラーをビルドフェーズに転送しますが、パッチのビルドフェーズにエラーを転送する必要はありません。
Teamcity + gerrit to the rescue
当社では、プロジェクトでコードレビューを実施するために、数年にわたってgerritが使用されています 。 チェックスタイルを使用してコードレビューをクロスしてみませんか。 グーグルと、曲がったスタイルの問題を完全に解決したいという願望を持って、彼はこの経済の設立に着手しました。 失敗した経験は省略し、今日まで機能している統合オプションについて説明します。
作業では、 コミットステータスパブリッシャープラグイン 、teamcity、gerritを使用します。
プラグイン自体は、バージョン7.1以降、teamcityに含まれています（混乱しない場合）。
チェックスタイル起動の構成
まず、チェックスタイルを実行する必要がある手順の1つであるビルドプランを作成します。
checkstyle：checkとcheckstyle：checkstyleの違いは、違反の場合、最初のファイルインアセンブリがプロジェクト全体を収集し、すべての違反に関するレポートを生成することです。
最良の方法は、checkstyle：checkstyleを最初のステップで開始し、chekstyle：checkinを2番目に開始して、アセンブリをファイルすることです。
コミットステータスパブリッシャーを追加
アセンブリに加えて、ビルドの追加機能により、コミットステータスパブリッシャーが追加されます。
設定は簡単です-gerritサーバーのアドレス、アセンブリの送信元のgitルート、gerritに侵入するログインを指定します。 公開キーを使用したgerritでの認証。したがって、teamcityサーバーとエージェントでキーペアを生成し、gerritに登録します。
アセンブリの起動を提供します
レビュー用の新しいコミットが表示されたときにアセンブリが自動的に開始されるようにアセンブリを構成することのみが残ります。 これを行うには、[トリガーのビルド]セクションで、新しいブランチリモート実行トリガーを追加します。 refs / changes / *ブランチで設定します。
私たちはチームシティに私たちは私たちだと確信させます
まあ、最も重要なこと。 Teamcityは、Branch Remote Run Triggerを使用して個人用アセンブリを起動します。つまり、アセンブリを開始するには、teamcityが作成者のユーザーを認識する必要があります。 teamcityがあなたを認識したかどうかを理解するために、アセンブリ履歴のコミットにカーソルを合わせることができます。 「TeamCityユーザー：不明」というテキストが表示される場合、これはもう1つの設定が必要であることを意味します。
同じダイアログに、VCSユーザー名の行があります。-その内容がコピーされ、teamcityユーザープロファイルに送信されます。 [バージョン管理のユーザー名設定]セクションで、コピーした値を「すべてのVCSルートのデフォルト：」に書き込みます。
レポートを公開する
別の項目-オプション-teamcityがチェックスタイルログを解析し、ビルド結果にスタイル違反を表示するように、「XMLレポート処理」と呼ばれるteamcityビルド機能で構成できます。 以下の設定例。
これらの設定後、コードをgerritのレビューに送信してみてください。 しばらくの間、アセンブリが開始され、結果に応じて、gerritに+1または-1が追加されます。 時間が経過してもアセンブリが開始されない場合は、teamcityログで理由を探してください。
説明した方法は、各コミットの単体テストの実行を制御することもできます。