Go Wiki: SlowBots

Goビルドシステムは「SlowBots」をサポートしています。これは、TryBots（プレサブミットビルダ）を設定して、TryBotsが通常実行するビルド構成セットに追加のビルダを追加する方法です。

通常、TryBotsは高速で弾力的にプロビジョニングされたもののみを実行します。つまり、TryBotsはGoogle Cloudで利用可能なポートのテストを実行します。そこには膨大なキャパシティがあり、多数のVMを自由に起動でき、テスト実行を広くシャード化することで、TryBotsは5〜10分で完了します。

しかし、それだけでは不十分な場合もあります。SlowBotsを使用すると、特定のビルダセットが利用可能になるまで長時間待つことを許容できます。（特定の構成には物理マシンが1台しかないことが多く、作業が滞留していることもあり、そのビルダも遅い場合があります。）

SlowBotsの使用方法

コミットメッセージの下にある「Tryjobsを選択」をクリックすると、ダイアログが表示されます。

A red box indicating the location of the “Choose Tryjobs” button under the commit message.

ダイアログでは、CLに対して実行したいビルドのチェックボックスをクリックするように求められます。メインのGoリポジトリへの典型的なCLでは、通常gotip-で始まるビルダが必要です。オプションの詳細については以下を参照してください。

An example of the Choose Tryjobs dialog.

実行したいビルドを選択したら、テスト実行をトリガーする方法は2つあります。

  • ブロッキング: これが推奨されるアプローチです。ダイアログに表示されるCq-Include-Trybotsgitフッターをコミットメッセージの最後の段落に追加します。github経由で送信されたCLの場合、github PRの説明のどこに表示されても問題ありません。更新されたコミットメッセージを持つパッチセットがアップロードされたら、通常どおりCommit-Queue+1を投票します。追加のビルドは、デフォルトのTryBotsと同様に扱われます。失敗すると送信がブロックされ、メール通知が送信され、ビルドは後続のパッチセットで自動的に実行されます（Cq-Include-Trybots行が残っている限り）。Cq-Include-Trybotsgitフッターは、コミットメッセージの最後の段落にない場合、使用されないことに注意してください。つまり、空行なしでChange-Id行のすぐ隣にある必要があります（以下のスクリーンショットを参照）。
  • アドバイザリのみ: 「追加」ボタンをクリックすると、すぐにテストが実行され始めます（Commit-Queue+1投票がなくても）。これらは完全に1回限りのアドバイザリビルドのみです。ステータスと結果は「Checks」セクションに表示されます（以下のスクリーンショットを参照）。ただし、失敗した結果は送信をブロックしたり、メール通知を送信したりしません。これらのビルドは、新しいパッチセットがアップロードされても自動的に再度実行されることはありません。

An example of how to use Cq-Include-Trybots

レビューアのワークフロー

レビューアはコミットメッセージを編集できません。レビュー中のCLがSlowBotsを実行する必要がある場合、以下のワークフローを推奨します。

  1. 「Tryjobsを選択」ダイアログで目的のビルドを選択します。
  2. 「追加」をクリックして、ビルドをすぐに開始します。
  3. オーナーに、ダイアログからの正確なCq-Include-Trybots行をコミットメッセージに追加するように求める未解決のコメントをコミットメッセージに追加します。

(2)は、オーナーが新しいパッチセットをアップロードするのを待たずにテストの結果から即座にフィードバックを提供し、(3)は、将来のパッチセットでもテストが実行され続け、送信がブロックされることを保証します。

注: https://crbug.com/40287467は、LUCIにおけるこのプロセスの改善を追跡し、手間を軽減します。

SlowBotの名前

各ビルドの名前は、その内容を大まかに示していますが、以下に詳細を説明します。

  • ビルドはx_$REPOで始まる場合があります。ここで$REPOはgolang.org/x/$REPOのようなモジュールです（例: x_review-gotip-linux-amd64）。このビルドは、そのリポジトリでテストを実行します。CLがメインのGoリポジトリのものである場合、そのバージョンのGoに対して$REPOの現在のHEADをテストします。
  • ビルドがx_$REPOで始まらない場合（例: gotip-linux-amd64）、メインのGoリポジトリ（標準ライブラリとツールチェーンを含む）をテストしています。
  • ビルドは、ビルド対象のGoバージョン（例: gotipまたはgo1.21）を常にリストします。前者はメインのGoリポジトリのmasterブランチに対してビルドし、後者は対応するリリースブランチのHEADに対してビルドします。CLが$REPOのものである場合、$REPOのテストは対応するメインのGoリポジトリブランチのHEADに対して実行されます。
  • 次に、ビルドはテスト対象のOSとCPUアーキテクチャ（具体的にはGOOSとGOARCH）をリストします。
  • 最後に、ビルドはgotip-linux-amd64-longtest-raceのような変更をリストします。以下に、いくつかの変更とその意味をリストします。
    • longtestは、対応するプラットフォームとリポジトリのテストスイート全体を実行します。
    • raceは、レース検出器の下でテストを実行します。
    • misccompileは、スモークテストとして、すべてのサポートされているプラットフォームのすべてのパッケージ（テストパッケージを含む）をクロスコンパイルします。これらのビルドのプラットフォームは、クロスコンパイルの「ホスト」プラットフォームです。

現在、実際にサポートされているまたは有効なビルドよりも多くの可能なビルドがリストされています。

期待どおりに機能するSlowBotsに関する一般的なガイドラインをいくつか紹介します。

  • golang.org/x/$REPOリポジトリのいずれかのCLに対してSlowBotsを実行している場合、すべてのx_$REPO-.*ビルダは期待どおりに機能します。その他のビルドは失敗します。
  • メインのGoリポジトリのCLに対してSlowBotsを実行している場合、CLが対象とするブランチに一致するすべてのビルドが機能します。たとえば、masterブランチのCLがある場合、gotipを含む名前のすべてのビルドは期待どおりに機能します（x_tools-gotip-linux-amd64、gotip-windows-amd64など）。release-branch.go1.21ブランチのCLがある場合、go1.21を含む名前のすべてのビルドは期待どおりに機能します（x_tools-go1.21-linux-amd64、go1.21-windows-amd64など）。

TODO: これらのガイドラインをフィルターとして自動的に適用します。

Pre-LUCI SlowBots

現在、Chromiumプロジェクトによって作成された新しいオープンソースCIシステムであるLUCIへの移行の途中です。上記の指示はLUCIでSlowBotsを実行する方法を説明していますが、すべてのポートがまだLUCIに移行されているわけではありません。その間、これらのポートは古いインフラストラクチャで引き続き利用できます。以下は、古いインフラストラクチャでSlowBotsを使用する方法の指示です。

  • GerritのウェブUIを使用して返信し、Commit-Queue = +1の代わりにRun-TryBot = +1を選択します。
  • 「送信」をクリックする前に、コメントセクション（「Say something nice...」と表示されているところ）にマジックコメントを書き込みます。
TRY=ppc64le, freebsd, netbsd-386, ios, linux-arm64-packet

... ここでTRY=の後の用語は次のいずれかです。

  • GOOS（最適なものを選択）
  • GOARCH（最適なものを選択）
  • GOOS-GOARCH（最適なものを選択）
  • specific-builder-name（正確な名前で明示的に指定します。完全なリストはhttps://farmer.golang.org/buildersを参照してください）

メインのGoリポジトリの場合、TRY=の後の用語は次のいずれかでも構いません。

  • x/repo。ここでrepoは、テストを実行すべきgolang.org/xリポジトリのいずれかです。これは、指定されたリポジトリのデフォルトビルダ（執筆時点ではlinux-amd64）を実行します。
  • x/repo@builder。ここでrepoは上記と同じで、builderはビルダリストのビルダ名です。これは、指定されたリポジトリの指定されたビルダを実行します。例: x/sys@linux-arm64-aws。

後でTryBotsを再度実行する場合、現在のパッチセットの最新のTRY=コメントが使用されます。これをオフにするには、等号の後に空文字列でTRY=を設定します。現在のパッチセットにTRY=コメントがない場合、最新のTRY=コメントが使用されます。

Pre-LUCI SlowBotsの落とし穴

  • TRY=コメントは、TryBotsを開始したコメントと同じコメントにない場合、無視されます。
  • TryBots-Resultがすでに存在する場合、TryBots（およびSlowBots）は実行されません。
  • git-codereview mailツールの-trybotフラグはまだこれをサポートしていないため、ウェブUIを使用してください。
  • TryBotsがすでに実行されている場合、Run-TryBot+1投票を削除して再度実行してもTryBotセットは再起動されないため、次回の実行が完了するまではTRY=行は考慮されません。（ただし、TryBot-Resultを何らかの方法で削除する必要があります: 手動で、リベースして、新しいバージョンをアップロードして）
  • オフラインのビルダを選択すると、現在のところ、それが表示されるまで永遠に待機します。タイムアウトはまだありません。
  • 不明なTRY=トークンを指定しても、それは無視され、エラーは報告されません。
  • allエイリアスはありません。これは意図的なもので、SlowBotsがすべての人にとってさらに遅くなる可能性のある過剰な使用を防ぐためです。しかし、後で追加する可能性もあります。golang.org/issue/34501#issuecomment-544585711を参照してください。

このコンテンツはGo Wikiの一部です。

go.dev は、サービスの品質を提供および向上させ、トラフィックを分析するために、Google の Cookie を使用しています。詳細はこちらをご覧ください。