greploop

Greploop

Greptile のフィードバックを参考に、依頼された変更を改善します。成功とは、未解決の対応可能な Greptile の指摘がない状態で、現在のリビジョンが新たに 5/5 のレビューを受けることです。ボットのスコアは、プロジェクトのチェックと自身の判断を補完するものです。

入力

• PR、MR、またはチェンジリストの番号。省略された場合は、現在のタスクから推測します。
• --max-iterations N：正の整数で、デフォルトはレビューサイクル 10 回です。
• --trigger @greptile がデフォルトです。別の経路を使う場合は @greptile-apps を指定します。通常のトリガーで変更ファイルが多すぎると報告された場合は、別の経路を使用します。
• --vcs github|gitlab|perforce：リポジトリのコンテキストが曖昧な場合に指定します。

ユーザーが許可した範囲とタスクのスコープに従ってください。読み取り専用のレビュー依頼は、コードの編集やコメントの投稿を許可するものではありません。自身のタスクのワークツリーとブランチを維持し、別のタスクのチェックアウトを PR ブランチに切り替えないでください。

プラットフォームの選択

インストール済みの実行ファイルだけでなく、リポジトリとセッションのコンテキストを利用してください。該当するリファレンスだけを読みます。

• GitHub：同梱のヘルパーは各トリガーを追跡し、現在のコミットに紐づくスコア付きレビューを待ちます。
• GitLab：ノートと解決可能なディスカッションを使用します。CI パイプラインのアクティビティだけでは Greptile のレビューを特定できません。
• Perforce：設定済みの Swarm またはサイトアダプターを使用します。

レビューサイクル

1. 対象のリビジョン、タスクの担当範囲がクリーンであること、実際に適用される反復上限を確認します。編集内容を公開する前に関連するチェックを実行し、変更をプッシュするかシェルブします。
2. プラットフォームのリファレンスに従ってレビューを 1 回開始します。トリガーとリビジョンを記録します。新しい結果が得られるまで最大 10 分待ちます。同じコミットに属するという理由だけで、以前のスコアを再利用しないでください。
3. 全般コメントの指摘も含め、新しいレビューの概要をすべて読みます。未解決の Greptile スレッドをすべてのページにわたって取得します。インラインコメントのリストが空でも、概要に対応事項が残っていないとは限りません。古い未解決スレッドも、行が古くなった後であっても、対処するまで引き続き関連性があります。
4. 現在のレビューが 5/5 で、対応可能な Greptile の指摘が残っておらず、関連するチェックに合格している場合は完了します。それ以外の場合は、各指摘を状況に照らして評価します。タスクの範囲内で妥当な問題を修正します。誤検知の場合は、解決する前に理由と裏付けとなる根拠を記録します。スコアを追い求めるためだけに正しいコードを変更したり、他のレビュー担当者のスレッドを解決したりしないでください。
5. 修正のチェックを実行します。タスクのファイルだけをコミットしてプッシュするか再度シェルブし、修正内容を公開したスレッドのみを解決します。ステージング時は明示的にファイルパスを指定します。コードを変更していない場合は、コミットとプッシュを省略します。
6. 上限内であれば、変更後のリビジョンについて新しいレビューを開始します。HEAD が変わると、以前の試行は無効になります。ポーリング結果がまだ返っていないという理由だけで、試行ファイルを再利用したり再トリガーしたりしないでください。

上限に達した場合、レビューがタイムアウトした場合、連携機能を利用できない場合、または残りの指摘にスコープの判断が必要な場合は停止します。実際の結果と残作業を報告してください。上限を自動的に引き上げたり、途中結果を完了としたりしないでください。編集が発生しなかったレビューも、反復上限に含まれます。

報告

PR/MR の URL またはチェンジリスト、レビューしたリビジョン、サイクル数、現在のスコア、実行したチェック、解決した指摘、残っている指摘を報告します。レビューが成功した場合と、タイムアウトまたは上限到達の場合を区別してください。依頼されていない限り、マージしないでください。