あなたが読んだ場合 前 このブログ投稿 シリーズここまで読んでいただければ、ウィザードを使って独自の品質ゲートを設計する方法について、すでに十分に理解されているはずです。このガイドを読み終えれば、あなたもウィザードと呼べるでしょう。非常に複雑な品質ゲートで構成される、非常に強力なポリシーを設計します。すべての手順は、まずグラフィカルな品質ゲートウィザード内で実行されます。内部で何が行われているのかを知りたい方のために、ウィザードによって生成されるXMLドキュメントの抜粋もお見せします。 safe品質ゲートを強化するバックエンドを独自に開発する予定がない場合は、これらの詳細は無視してください。ただし、この考え方を試してみる場合は、グラフィカルウィザードを使用せずに、宣言型言語で指定された品質ゲートをデプロイする方法も説明します。

あなたの報酬 – パワー例

ウィザードと送信ルール評価アルゴリズムの最後の秘密を明かす前に、参加していただいた特典をお知らせしたいと思います。これから設計するポリシーは、以下の手順で構成されています。

1. 少なくとも1人のユーザーが コードレビュー+2 作者は自分のコミットを承認できません（投票は無視されます）

2. コードレビュー -2 ブロック送信

3. 検証済み -1 ブロック送信

4. 少なくとも2人のCIユーザー（Gerritグループに所属） CI-ロール）与えなければならない 確認済み +1 変更を送信する前に

5. チームリーダー（Gerritユーザーのリスト）のみが提出できます

6. というファイルの場合 COPYRIGHT コミット内で変更されると、Gerritグループと呼ばれる 規約とポリシー 承認する必要がある（コードレビュー +2）Gerritの変更

最終ポリシーは以下からダウンロードできます。 こちら法務グループとCIグループのテクニカルグループID、そしてチームリーダーの具体的なユーザー名が異なるため、そのままではご利用いただけませんのでご注意ください。具体的な状況に適した結果を得る方法について、手順を追ってご案内いたします。

既知のものから始める – Gerritのデフォルトの送信ポリシー

手順1、2、3をご覧いただければ、Gerritのデフォルトの送信ポリシーと非常によく似ていることにお気づきでしょう。そこで、まずはテンプレート「Gerritのデフォルトの送信ポリシー」を読み込んでみましょう。エディターの最初のタブが表示されたら、下のスクリーンショットのように名前と説明を調整してください。

ここで [ソース] タブ (3 番目) に切り替えると、ウィザードが既定のポリシー用に生成した XML が表示されます。

ここでご覧いただけるXMLベースの言語は、Gerrit Quality Gateバックエンドによって実装されています。この言語は、カスタムPrologスニペット（ デフォルトの方法 Gerritの送信動作をカスタマイズする方法（例：Gerritの送信動作をカスタマイズする方法）に加えて、Prologファクトとして公開されていないGerritの一部の機能（ユーザーグループ情報など）も公開されます。Quality GateバックエンドはGerritプラグインとして実装されており、カスタムProlog述語を提供します。この述語はXMLベースの言語を解析し、GerritのPrologエンジンに適切な指示を与えます。この詳細は、独自のPrologスニペットをウィザードで生成されたポリシーと組み合わせる場合にのみ関係すると思われます。

私たちの言語を記述するスキーマは こちら上のスクリーンショットを見ると、XMLのトップ要素が ジェリットワークフロー ウィザードの最初のタブのすべての設定が含まれています。名前、説明、 コードレビューを有効にする の三脚と 検証を有効にする最後の 2 つは、ユーザーにコードレビュー/検証済みカテゴリへの投票機能を提供するかどうかの情報 (適切な権限が付与されている場合) を保存します。

受け入れられる唯一の子要素は ジェリットワークフロー 要素は 送信ルールデフォルトポリシーの3つの送信ルールを明確に確認できます。詳細については、 2番目の ブログ投稿。最初の送信ルール「 コードレビュー+2-検証済み-提出投票条件がすべて満たされた場合、許可と評価され、他のルールが評価されなければ送信が可能になります。 コロナ新型ウィルス(COVID-XNUMX)やメンタルヘルスの崩壊を避ける為のこのルールでは、 満足しなかった場合のアクション 属性の場合、次のように評価されます 無視する 投票条件がすべて満たされていない場合。投票条件について言えば、2つの条件があります。 投票条件 子要素。最初の要素は、誰かが コードレビュー +22番目は誰かが与えた場合 確認済み +12番目の SubmitRule 要素は、パワー例のステップ2に直接マッピングされます（ コードレビュー -2 ブロックの送信）、3番目のブロックは直接ステップ3に進みます（検証済み -1 ブロックの送信)。

投票フィルターを導入して著者の投票を無視する

最初の送信ルールを、パワーサンプルポリシーの最初のステップと一致するように変更しましょう。

「少なくとも1人のユーザーが コードレビュー+2 作者は自分のコミットを承認できません（投票は無視されます）”

まず、ウィザードの2番目のタブ（送信ルール）に切り替え、最初の送信ルールをダブルクリックします。次に、最初の投票条件（コードレビュー）をダブルクリックし、 著者を無視 開いたダイアログの投票チェックボックスを選択します。下のスクリーンショットを参照してください。

この変更を保存し (2 つのダイアログで [完了] を押す)、[ソース] タブに戻ると、最初の送信ルールの XML が変更されていることがわかります。

最初のVotingCondition要素には、 投票著者フィルター 子要素です。この要素には 著者投票を無視属性をtrueに設定すると、この投票条件が評価される際に、非著者の投票のみが考慮されるようになります。また、 非著者投票を無視 属性。これを使えば、条件を反転させることが可能です（ true）に設定し、著者の投票以外を無視します。両方の属性が trueの場合、すべての投票は無視されます。投票条件は常に、対象となるGerritの変更の最新の変更セットに適用されます。

検証済み投票条件にグループフィルターを追加する

パワーの例のステップ 1 を理解し、ステップ 2 と 3 はデフォルト ポリシーから変更せずにそのままにできることを確認したので、ステップ 4 に焦点を当てましょう。

「少なくとも2人のCIユーザー（Gerritグループに属する） CI-ロール）与えなければならない 確認済み +1 変更を送信する前に、「変更を送信する前に」を確認してください。

これは、最初の送信ルールの2番目の投票条件（Verified）を変更することで実現できます。今回は、著者によるVerified投票を無視するのではなく（同じチェックボックスを再度チェックするだけでも可能）、グループとカウントフィルターを追加します。

上のスクリーンショットのように、次のように入力します。 2 に 投票数最小値 フィールドに入力し、CIユーザーを表すGerritグループを選択します。ウィザードでは、 TeamForge グループ、 TeamForge プロジェクトの役割と内部の Gerrit グループ。

ダイアログを終了して [ソース] タブに戻ると、最初の送信ルールの 2 番目の投票条件が変更されていることがわかります。

2つのフィルターが表示されました。1つは 投票投票者フィルター そして、1 投票集計フィルター1つ目は、 CI_ロール （私たちは TeamForge プロジェクトの役割 役割1086 ここでのVotingConditionは、周囲のVotingConditionを評価するときに認識されます。

2つ目のフィルターは集計フィルターです。集計フィルターと合計フィルターは、同じVotingCondition内の他のすべてのフィルターが適用された後に適用されます。この例では、すべての投票が行われた後にフィルターが適用されます。

a) 投票カテゴリに該当しない Verified (親要素のvotingCategory属性)

b) 判定+1（親要素の値属性）を持たない

c) 当該キャンペーンの一部であるユーザーによってキャストされていない CI_ロール （上記の段落を参照）

フィルタリングされました。

その後、私たちの 投票集計 フィルターは、少なくとも2票（minCount属性）が残っている場合にのみ一致します。そうでない場合、周囲のVotingConditionは満たされず、結果として、周囲のSubmitRuleも満たされません。

SubmitRuleフィルターの導入

これまでは投票条件とその子フィルター要素についてのみ説明しました。特定の条件が満たされない場合、送信ルール全体を評価したくない場合があります。2つ目のブログ記事では、コミットがexperimentalブランチを対象としている場合にのみ評価する必要があるルールに対して、送信ルールフィルターを使用しました。

パワーポリシーのステップ5は別の例です。「チームリーダー（Gerritユーザーのリスト）のみが送信できます」

最初の送信ルールにフィルターを追加し、チームリーダーが Gerrit の変更を確認した場合にのみ評価されるようにします。現時点では送信ルールは 3 つしかなく、評価されて許可される可能性があるのは最初のルールだけなので、このフィルターは最初のルールにのみ追加すれば十分です。そのためには、「送信ルール」タブに戻り、最初の送信ルールをダブルクリックして、開いたダイアログで「次へ」ボタンをクリックします。すると、利用可能なすべての送信ルールフィルターをグループ化した 4 つのタブが表示されます。これらのタブは、既存の Gerrit 変更 (より正確には、最新の変更セット) の特性に基づいて、フィルターの値が自動的に入力された 2 番目のブログ投稿で紹介したことを覚えているかもしれません。

今回は、必要なフィルター値を手動で入力します。「ユーザー」タブに切り替えて、チームリーダーのアカウントを選択しましょう。下のスクリーンショットでは、以下のアカウントを選択しています。 エシマンスキ の三脚と シェタ チームリーダーとして。

代わりにチームリーダーを選択すると（ウィザードを使用すると対話的に選択できます） TeamForge ユーザーまたは内部 Gerrit アカウント) を変更するには、[戻る] をクリックして、最後に送信ルールの表示名を新しい意味に合わせて調整します。 コードレビュー+2 つの CI とプロジェクト リーダーによる検証済み、提出用

ダイアログを終了して [ソース] タブに戻ると、最初の送信ルールの displayName が変更されただけでなく、新しい子要素も取得されていることがわかります。

その ユーザーフィルター 要素は、その周囲の送信ルールが、その中の少なくとも1つが満たされている場合にのみ評価されることを保証します。 現在の使用者 子要素は、現在 Gerrit の変更を表示しているユーザーと一致します。

複数の送信ルールフィルターがある場合、周囲の送信ルールを評価するには、それらすべてが一致する必要があります。一致するフィルターがないため、送信ルールを評価できない場合はどうなるのでしょうか？その場合、送信はブロックされ、GerritのWeb UIにメッセージが表示されます。送信ルールを全く定義していない場合も同様です。デプロイ前に、ウィザード内で既存の変更に対して送信ルールを直接テストできます。

表示のみのルールでユーザーにガイダンスを提供する

最終ステップ（6）の送信ルールを設計する前に、送信ルールの評価アルゴリズムと、現在のポリシーでチームリーダー以外の人がGerritの変更を確認した場合に何が起こるかを思い出してみましょう。ブログ投稿からの引用です。 2:

a) 評価可能なすべての送信ルールについて、その投票条件が満たされているかどうかを判断します（送信ルールに投票条件がない場合は、自動的に満たされます）

b) 送信ルールのすべての投票条件が満たされた場合、ルールは指定されたアクションに評価されます。 アクションIfSatisfiedField （値が設定されていない場合は無視されます）、それ以外の場合はルールは指定されたアクションに評価されます 満足しなかった場合のアクション フィールド

c) 評価された送信ルールのいずれかがブロックと評価された場合、送信は無効になり、この決定の理由として、すべてのブロックルールの表示名が Gerrit の UI に表示されます。

d) 評価された送信ルールが評価されなかった場合 コロナ新型ウィルス(COVID-XNUMX)やメンタルヘルスの崩壊を避ける為の しかし少なくとも1つは 許す送信が有効になります

e) すべての評価されたルールが無視されると、送信は無効になり、すべての潜在的な送信ルール候補の表示名が表示されます。

最初の送信ルールとして（コードレビュー+2 つの CI とプロジェクト リーダーによる検証済み、提出用）には送信ルールフィルターがありますが、チームリーダーでない場合はこのルールは評価されません。つまり、送信ルールは2つ（コードレビュー-拒否-ブロック-送信）と3つの（検証済み-拒否-ブロック-送信）。どちらの送信ルールにも送信ルールフィルターがないため、常に評価されます。どちらのルールにも投票条件が1つあり、 コードレビュー -2 or 検証済み -1 投票します。対応する投票条件を満たす場合、周囲の送信ルールがブロックと評価され、送信がブロックされ、GerritのWeb UI内に理由として表示名が表示されます。

今のところ、Gerrit の変更に対して誰も拒否権を行使していないと仮定しましょう。その場合、評価されたすべてのルールは無視すると評価され、アルゴリズムの最終ステップ (e) が実行されます。送信は無効になり、すべての送信ルール候補の表示名、つまり、許可すると評価される可能性のあるすべての評価済み送信ルールが表示されます。ただし、今回の場合、許可すると評価される可能性のある送信ルールは送信ルール 1 のみであるため、送信ルール候補はありません。ただし、この送信ルールは、送信ルール フィルターが一致しなかったため評価されませんでした (変更を確認しているチーム リーダーがいなかった)。その結果、Gerrit は送信ができない理由を示す非常に一般的なメッセージのみを表示し、チーム リーダー以外のユーザーは何を待てばよいのか混乱してしまいます。

このような状況でどのようにガイダンスを提供するのでしょうか？アルゴリズムを修正し、評価されなかった送信ルールの表示名も表示するようにすればいいのでしょうか？おそらくそうではないでしょう。Apopheniaというグループに秘密の品質ゲートがあり、そのグループがenigmaブランチへのコミットで、コミットに追加された行数が23行であれば他の品質ゲートをバイパスできると想像してみてください（私が何を言っているのかわからない人のために、私は本当に次のことを勧めます）。 この映画).

対応する送信ルールには、送信ルールフィルターが設定され、特定のブランチ、コミット統計、ユーザーグループに対してのみルールが評価されるようにします。これらのフィルターが一致しない限り、送信ルールの表示名はいかなる状況においても公開されません。同様の特性を持つ、よりビジネスライクなシナリオを想像できるでしょう。

幸いなことに、そのような状況でユーザーを誘導する方法があります。ルールのみを表示する

表示のみのルールは、投票条件や送信ルールフィルターのない送信ルールです。したがって、常に評価され、常に条件を満たします。ただし、actionIfSatisfied属性には値（あるいは無視）が設定されていません。したがって、送信の有効/無効に影響を与えることはありません（これが表示のみと呼ばれる理由です）。 満足しなかった場合のアクション 属性がに設定されている 許すこれにより、これらのユーザーは送信ルールの候補として扱われます。つまり、他の送信ルールで送信が許可またはブロックされていない場合でも、これらのユーザーの表示名が常に表示されるため、完璧なガイダンスとなります。

この例では、表示名 Team-Lead-To-Submit の表示のみのルールを作成し、変更を拒否した人がいないにもかかわらず、送信できない理由をチーム リーダー以外の全員に示します。

ここで、「ソース」タブのもう一つの便利な機能をご紹介します。これは双方向なので、XMLを編集することもでき、変更内容はウィザードの1つ目と2つ目のタブに反映されます。表示のみのルールをGerritWorkflow要素の子要素として貼り付けてみましょう。

「送信ルール」タブに戻ると、次のようになります。

おそらくお気づきかと思いますが、「Not Satisfied Action」フィールドは今回が初めてです。確かに、これは表示のみのルールという、かなり特殊なユースケースでの使用です。パワーポリシーの最終ステップでは、このフィールドのより一般的なユースケースをご紹介する予定です。

例外駆動ルールの不満足アクション

電源ポリシーのステップ 6 は、例外駆動ルールと呼ばれる例です。

「 COPYRIGHT コミット内で変更されると、Gerritグループと呼ばれる 規約とポリシー 承認する必要がある（コードレビュー +2）Gerritの変更

なぜ例外駆動なのでしょうか？法務部門の承認を得るだけでは、送信を有効にするには不十分です。そのため、actionIfSatisfiedをallowに設定した別の送信ルールを用意するのは解決策ではありません。では、送信を有効にする可能性のあるすべての送信ルールに、法務部門の承認を投票条件として追加すればよいのでしょうか？これもおそらく良い考えではありません。すべてのコミットが法務部門の承認を受ける必要はなく、変更を加えたコミットだけが承認されれば十分です。 COPYRIGHTファイルにソフトウェアを指定する必要があります。

したがって、既存の送信ルールを変更せずに、新しい送信ルールを追加するのが最善の策です。

I) 評価された場合、法務部門が変更を承認したかどうかを確認し、承認されていない場合は送信をブロックします（例外駆動型）

II) 法務部門が実際に変更を承認する必要がある場合にのみ評価される（著作権ファイルが変更された場合）

まず、表示名で新しい送信ルールを作成して（ルールを手動で追加するボタンを押して）、I)に取り組みましょう。 著作権ファイルの変更を承認する法的権限 不満足時のアクションを コロナ新型ウィルス(COVID-XNUMX)やメンタルヘルスの崩壊を避ける為の.

新しい送信ルールをこのように維持すると、投票条件がないため、単一の変更をブロックしません（したがって、常に満足と評価されます）。そこで、Gerritグループを必要とする投票条件を追加してみましょう。 規約とポリシー 与える コードレビュー +2以下のスクリーンショットは、この条件がどのように表示されるかを示しています。この例では、Legalは TeamForge ユーザーグループ（group1008).

現状では、新しい投票条件を満たさないすべての変更はブロックされます。

II) を実装することで、対応するコミットで COPYRIGHT ファイルが変更された場合にのみ、この送信ルール（および投票条件）が評価されるようになります。そのためには、「次へ」をクリックし、「コミットの詳細」タブに切り替えます。このタブには、評価対象の変更に関連付けられたコミットの特性に一致するすべての送信ルールフィルターが含まれています。入力する必要があるフィールドは「コミット差分ファイルパターン」のみです。以下のスクリーンショットに示すように、値は ^COPYRIGHT に設定する必要があります。

Why ^著作権 だけでなく COPYRIGHT? フィルター名が「パターン」で終わらない場合は、完全に一致する値のみに一致します。フィルター名が「パターン」で終わる場合は、フィールド値に応じて一致が異なります。

フィールド値が ^、フィールド値は正規表現として扱われます。 ^著作権 を含むファイル変更リストに一致します COPYRIGHT どこかに。フィールド値が^で始まっていない場合は、正確な値として扱われます。COPYRIGHTだけを入力した場合、COPYRIGHTのみが変更されたコミット（他のファイルは変更されていない）のみが一致します。パターンフィルターを使用する際は、常にこのロジックを念頭に置いてください。ブランチフィルターやコミットメッセージフィルターは、正確な値よりも正規表現を使用する方が適している代表的な例です。

ダイアログを終了して「ソース」タブに切り替えると、新しい送信ルールの XML が表示されます。

actionIfNotSatisfied 属性はブロックに設定されており、送信ルール フィルター (CommitDetailFilter) が 1 つと、フィルター付きの投票条件 (VoteVoterFilter) が 1 つあります。

おめでとうございます。電源ポリシーの設計は正常に完了し、テストと展開を行うことができます。

XMLベースの品質ゲート言語についてさらに学ぶ

これまでXMLベースの言語についてかなり詳しくご紹介してきましたが、すべての機能を網羅できていないことは重々承知しています。しかし、グラフィカルなウィザードで言語のすべての機能をサポートしているため、すべての機能をご紹介する必要はないと考えています。特定のフィルターの動作が不明な場合は、ウィザードでサンプルを1つ作成し、「ソース」タブに切り替えて、適切な設定方法を確認してください。 スキーマ これも優れたリソースです。ドキュメントが充実しており、無効なXMLドキュメントを作成してしまう心配がありません。最後に、ウィザードには多数の定義済みテンプレートが付属しています。これらのテンプレートでは、言語のあらゆる機能を網羅するよう努めました。

ご存知の方には GerritのPrologクックブック全てのPrologの例を宣言型言語に変換し、実証された機能全体をカバーできました。結果は以下をご覧ください。 こちら.

いつものように、言語に関してご質問がある場合は、このブログにお気軽にコメントをお寄せください。

グラフィカルウィザードを使わずに品質ゲートを展開する方法

前述の通り、Quality Gate 強制プラグインは Gerrit の Prolog ベースのメカニズムと連携して、送信動作をカスタマイズします。Gerrit は、現在の送信ルールを以下の Prolog ファイルに格納することを想定しています。 ルール.pl 特別な参照で refs/meta/config. rules.plの導入プロセスについて説明します こちら.

ウィザードがrules.plファイルを生成するときは、カスタムProlog述語を使用します。 cn:ワークフロー/2これはQuality Gate強化プラグインによって提供されます。この述語には2つの引数があります。1つ目はXMLコンテンツをそのまま受け取り、2つ目はGerritのボディにバインドされます。 送信ルール/1 述語。簡単に言うと、生成されたrules.plは次のようになります。

送信ルール(Z):-cn:ワークフロー(' '、Z)。

このウィザードは他のProlog述語を一切使用しません。独自のツールを開発し、rules.plを自分で生成する場合は、この述語を独自のPrologプログラムの一部として使用できます。XMLコンテンツを渡す際は、Prologの引用符を破る文字（'文字、改行、XMLエンコードは不可）が含まれていないことを確認してください。この手順は、グラフィカルなウィザードが行います。

締めくくりの言葉と参加の呼びかけ

3番目のブログ記事を最後まで読み終えたなら、あなたも自分を魔法使いと自慢できるでしょう。 

高品質なゲートをゼロから設計するのは複雑な作業になりがちです。幸いなことに、当社のウィザードには、そのまま使える定義済みのテンプレートが多数用意されています。さらに、Prologクックブックのあらゆる例を、当社のツールに組み込みました。 形式でアーカイブしたプロジェクトを保存します．Gerritの変更における特定の状態をどのようにマッチングすればよいかわからない場合は、ウィザードの組み込み機能を使用して送信ルールに変換し、ニーズに合わせて適用してください。デプロイ前に、ウィザード内で品質ゲートをシミュレートできます。送信ルールの評価アルゴリズムを段階的に実行し、各ルールの評価結果を表示します。ウィザードとPrologの両方が気に入らない場合は、XMLベースの言語を単独で使用することもできます。このブログ記事では、その方法について説明しています。

XMLベースの言語について言えば、その仕様はオープンソースです。独自のウィザードやその他のフロントエンドの構築を歓迎します。機能に関するご質問があれば、喜んでお手伝いいたします。Gerritの送信動作をカスタマイズする機能は業界で他に類を見ません。私たちの貢献によって、Gerritの活用が少しでも容易になれば幸いです。

ウィザード、言語、そしてバックエンドの開発はチームワークでした。現状に至るまで、約6人が2ヶ月間かけて取り組んできました。この分野へのさらなる投資が必要かどうか、ぜひご意見をお聞かせください。もっと多くの例が欲しいですか？ドキュメントをもっと充実させたいですか？チュートリアルビデオが欲しいですか？Web UIベースのウィザードが欲しいですか？パフォーマンスに問題がありますか？思い通りのルールを表現できませんか？この機能を標準のGerritで使いたいですか？

この新機能についてぜひ広めて、フィードバックをお寄せください。