LLVM Buildbot インフラストラクチャにビルド設定を追加する方法

はじめに

このドキュメントは、プライベートワーカービルダーにビルド設定と buildbot-worker を LLVM Buildbot インフラストラクチャに追加する方法について説明しています。

ビルドマスター

2 つのビルドマスターが実行されています。

  • https://lab.llvm.org/buildbot にあるメインビルドマスター。このマシンに接続されているすべてのビルダーは、ビルドが壊れるたびにコミット作成者に通知します。

  • https://lab.llvm.org/staging にあるステージングビルドマスター。このマシンに接続されているすべてのビルダーは、ビルドが壊れた場合、デフォルトで完全にサイレントになります。このビルドマスターは、llvm-zorg リポジトリからの新しいコミットを使用して 2 時間ごとに再構成されます。

メインビルドマスターに接続されたままでいるためには（したがって、開発者に障害を通知するためには）、ビルドボットは

  • サポートされている構成をビルドしている必要があります。実験的なバックエンドのビルダーは、一般的にステージングビルドマスターに接続する必要があります。

  • メインブランチへの新しいコミットに対応できる必要があります。または、少なくとも、遅れてから数日以内にツリーの先端まで回復できる必要があります。

さらに、すべてのボット所有者は、メンテナンス期間中、不安定性のトラブルシューティングなどの際に、ボットをステージングマスターに向けることをお勧めします。

役割と期待

各ビルドボットには、ビルドボットで発生する問題に対処する責任者である所有者がいます。ボット所有者は、合理的に迅速に対応することが期待されています。

一部のボットでは、所有権の責任は、基盤となるマシンリソースを提供する「リソース所有者」と、ビルド設定を維持する「設定所有者」に分割されます。一般的に、運用上の責任は「設定所有者」にあります。通常、ワーカーの属性に記載されている連絡先である「リソース所有者」は、関連する「設定所有者」にリクエストを適時にプロキシすることが期待されています。

ビルドボットに関するほとんどの問題は、メールでボット所有者に直接対処する必要があります。Galina Kistanova を CC に入れてください。

LLVM Buildbot にビルダーを追加する手順

ボランティアは、ビルドマシンをパブリック LLVM Buildbot のビルドワーカーとして提供できます。

そのための手順は次のとおりです。

  1. 既存のビルド設定を確認して、興味のある設定がまだカバーされていないか、既存の設定よりもコンピューターで znacznie高速にビルドされることを確認してください。開発者が変更のコミット後すぐにフィードバックを受け取ることができるように、高速なビルドが推奨されます。

  2. LLVM buildbot インフラストラクチャに登録するコンピューターには、すべての依存関係がインストールされており、設定を正常にビルドできる必要があります。どの程度の並列度（-j パラメータ）が最速のビルドを提供するかを確認してください。1 台のコンピューターで複数の設定をビルドできます。

  3. buildbot-worker をインストールします（現在、buildbot バージョン 2.8.4 を使用しています）。この特定のバージョンは、pip3 install buildbot-worker==2.8.4 などのコマンドを使用して pip を使用してインストールできます。

  4. buildbot-worker が実行される専用のユーザーアカウントを作成し、適切な権限を設定します。

  5. buildbot-worker のルートディレクトリ（すべてのビルドは、このディレクトリの下に配置されます）、buildbot-worker のアクセス名とパスワード（ビルドマスターが buildbot-worker の認証に使用する）を選択します。

  6. buildbot-worker アカウントのコンテキストで buildbot-worker を作成します。ポート **9994** の **lab.llvm.org** をポイントします（詳細については、Buildbot ドキュメント、ワーカーの作成 を参照してください）。次のコマンドを実行します。

    $ buildbot-worker create-worker <buildbot-worker-root-directory> \
             lab.llvm.org:9994 \
             <buildbot-worker-access-name> \
             <buildbot-worker-access-password>

    新しいワーカーが安定し、Galina からの承認を受け取った場合にのみ（最後のステップを参照）、メインビルドマスターをポイントする必要があります。

    ワーカーを起動します

    $ buildbot-worker start <buildbot-worker-root-directory>

    これにより、新しいワーカーは、デフォルトでサイレントであるステージングビルドマスターに接続します.

    これを 1 回試してから、ログファイル <buildbot-worker-root-directory>/worker/twistd.log を確認してください。設定が正しい場合は、接続が拒否されたことが表示されます。これは正常であり、予期された動作です。資格情報が両端で確立されていないためです。ワーカーを停止して、次の手順に進みます。

  7. buildbot-worker の説明と管理者の名前/メールアドレスを入力します。buildbot-worker の説明の例を次に示します。

    Windows 7 x64
Core i7 (2.66GHz), 16GB of RAM

g++.exe (TDM-1 mingw32) 4.4.0
GNU Binutils 2.19.1
cmake version 2.8.4
Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86

    編集するファイルについては、こちら を参照してください。

  8. ビルドワーカーとビルダーを zorg に追加するパッチを送信します。典型的な LLVM ワークフロー を使用してください。

    • ワーカーは buildbot/osuosl/master/config/workers.py に追加されます

    • ビルダーは buildbot/osuosl/master/config/builders.py に追加されます

    ビルダー名とその builddir がファイル全体で一意であることを確認してください。

    すべての新しいビルダーは、デフォルトで「「collapseRequests」: False」設定を使用する必要があります。これにより、ビルダーは各コミットを個別にビルドし、ビルドリクエストをマージしません。開発者へのフィードバックの質を最大限に高めるために、ビルダーがリクエストを折りたたみ *ないように* 設定することを *強くお勧めします*。このフラグは、ビルダーがコミットフローに対応できるようにビルド時間を改善するためのあらゆる合理的な努力が尽くされた後にのみ削除する必要があります。

    メールアドレスがビルドの失敗時に無条件に通知を受け取ることを許可できます。このためには、InformativeMailNotifier を buildbot/osuosl/master/config/status.py に追加する必要があります。これは、そうでなければサイレントであるステージングビルドマスターにとって特に役立ちます。

  9. buildbot-worker のアクセス名とアクセスパスワードを Galina Kistanova に直接送信し、変更が適用され、ビルドマスターが再構成されたことが通知されるまで待ちます。

  10. buildbot-worker を起動して、サイレントビルドマスターに正常に接続できることを確認してください。次に、起動時に buildbot-worker が自動的に起動するように設定します。ヘルプについては、buildbot のドキュメントを参照してください。動作を確認するためにコンピューターを再起動する必要がある場合があります。

  11. ウォーターフォールディスプレイ（ステージング） で buildbot-worker のステータスを確認して、接続されていることを確認し、ワーカーディスプレイ（ステージング） で管理者の連絡先とワーカー情報が正しいことを確認します.

  12. この時点で、ステージングビルドマスターに接続された動作中のビルダーがあります。これで、信頼性の高いグリーンであり、ビルドキューに対応していることを確認できます。通知は送信されないため、不安定なビルダーを無期限にステージングに接続したままにすることができます。

  13. （オプション）ビルダーがステージングビルドマスターで安定し、数日間のグリーン履歴がある場合は、本番ビルドマスターに移動して開発者への通知を有効にすることを選択できます。レビューと承認については、Galina Kistanova にメールを送信してください。

    ワーカーを本番環境に移動するには（承認後）、ワーカーを停止し、buildbot.tac ファイルを編集してポート番号を 9994 から 9990 に変更し、再起動します。

高速ビルダーを構成するためのベストプラクティス

前述のように、一般的に、コミットが入ってくるたびにビルドできるビルダーが強く推奨されます。このセクションでは、その目的を達成するためのベストプラクティスといくつかの推奨事項について説明します。

目標

2020 年、モノレポには 3 万 5 千件弱のコミットがありました。これは、1 時間あたり平均 4 コミットになります。すでに、ビルダーが役立つためには 15 分以内にサイクルする必要があることがわかります。ただし、これらのコミットは均等に分散されていません。米国の営業時間中に強くクラスター化する傾向があります。最近の（2021 年 11 月）数営業日を見ると、ピーク時には 1 時間あたり約 10 コミットが日常的に発生し、1 時間あたり約 15 コミットのスパイクが時折発生します。したがって、経験則として、ビルダーが 1 時間に約 10 ～ 15 ビルドを完了するように計画する必要があります。

リソースの適切な割り当て

1 時間あたり 10 ～ 15 ビルドでは、平均 4 ～ 6 分ごとに新しいビルドを完了する必要があります。最速のハードウェア/ビルド設定を除いて、これは単一マシンの能力をはるかに超えています。buildbot の用語では、単一のビルダー設定でリクエストを並行してビルドするために、複数のワーカーが必要になる可能性があります。大まかな概算値として、ビルド設定に 30 分かかる場合、5 ～ 8 人程度のワーカーが必要になります。ビルド設定に約 2 時間かかる場合、20 ～ 30 人程度のワーカーが必要になります。このセクションの残りの部分では、サイクルタイムを短縮する方法に焦点を当てます。

ビルドとテストの対象を制限する

ボットを設定する理由をよく考えて、ビルド設定をできるだけ制限してください。基本的な機能はおそらく他のボットでカバーされているため、そのテストを複製する必要はありません。設定の *一意の* 部分のみをビルドおよびテストする必要があります。（たとえば、マルチステージの clang ビルダーの場合、すべてのターゲットを有効にしたり、さまざまなユーティリティをすべてビルドしたりする必要はおそらくありません。）

同じビルダーに複数の異なる目的がある場合、単一のビルダーを 2 つ以上に分割する価値がある場合があります。たとえば、a）LLVM がホストコンパイラでビルドされることを確認し、b）ターゲットでマルチステージの clang ビルドを実行する場合、2 つの個別のボットを使用する方がよい場合があります。分割するとリソース消費量が増加しますが、各ボットがコミットフローに対応しやすくなります。さらに、ボットを分割することで、失敗した設定の関連部分に注意を絞ることができるため、トリアージに役立つ場合があります.

一般的に、アサーションが有効になっているリリースビルドタイプをお勧めします。これは、ほとんどのビルドボットで、ビルド時間とバグ検出のバランスがとれています。デバッグ情報をいくつか含める余地がある場合がありますが（-gmlt など）、一般的に、デバッグ情報の品質とビルド時間のバランスは微妙です。

Ninja と LLD を使用する

Ninja は、特に高度に並列化されたビルドでは、Make よりもビルド時間を短縮するのに役立ちます。LLD は、リンク時間とリンク中のメモリ使用量の両方を大幅に削減するのに役立ちます。十分な並列処理能力を備えたビルドマシンでは、リンク時間がビルドのクリティカルパスの大部分を占める傾向があるため、最適化する価値があります。

CCache を使用し、増分ビルドは使用しない

ccache を使用すると、平均ビルド時間が大幅に短縮されます。インクリメンタルビルドはわずかに高速になる可能性がありますが、状態変更などによるビルド破損のリスクが生じます。現時点では、インクリメンタルビルドを使用せず、ccache を使用することをお勧めします。ccache は、誤検知のリスクが少なく、利点の大部分を享受できるためです。

ccache を使用するあまり知られていない利点の 1 つは、どのプロジェクトが監視されているか、ビルドされているかに対するビルダーの感度が低下することです。変更によってビルドリクエストがトリガーされても、ビルド出力が変更されない場合（ドキュメントの変更、Python ユーティリティの変更など）、ビルドは完全にキャッシュにヒットし、ビルドリクエストはテスト時間だけで完了します。

複数のワーカーを使用する場合、ワーカー間で共有キャッシュを構成したくなるかもしれません。これまでの経験では、これを適切に行うのは難しいことが示されており、ワーカーごとにローカルキャッシュを持つことで、ほとんどの利点が得られます。現在、共有キャッシュは推奨していません。

ccache は、ビルダーハードウェアが妥当なアクセス時間でキャッシュにアクセスするための十分な IO（高速ディスク、RAM キャッシュ用の十分なメモリなど）を備えていることに依存します。そうでないビルダーの場合、インクリメンタルビルドが最良の選択肢となる可能性がありますが、スポンサーからの継続的な関与が必要になる可能性が高くなります。

バッチビルドを有効にする

最後の手段として、ビルドリクエストをバッチビルドするようにビルダーを構成できます。これにより、ビルド失敗通知の実用性が著しく低下するため、他のすべての合理的な対策を講じた後にのみ実行する必要があります。

ステージングビルドマスターのままにする

このセクションのほとんどは、メインビルドマスター向けのビルダーに偏っていますが、ビルダーはステージングビルドマスターで無期限に実行できることを強調しておく価値があります。このようなビルダーは、より広範なコミュニティに悪影響を与えることなく、スポンサー組織にとって依然として有用である可能性があります。スポンサー組織は、すべての二分探索とトリアージの責任を負う必要があります。