このページでは、密閉性、密閉ビルドを使用するメリット、ビルドで非密閉動作を特定するための戦略について説明します。
概要
同じ入力ソースコードとプロダクト構成が指定された場合、密閉ビルドシステムは、ホストシステムの変更からビルドを分離することで、常に同じ出力を返します。
ビルドを分離するために、密閉ビルドはローカルまたはリモートのホストマシンにインストールされているライブラリやその他のソフトウェアに影響を受けません。コンパイラなどのビルドツールや、ライブラリなどの依存関係の特定のバージョンに依存します。ビルド環境の外部のサービスに依存しないため、ビルドプロセスは自己完結型になります。
密閉性の重要な側面は次の 2 つです。
- 分離: 密閉ビルドシステムはツールをソースコードとして扱います。ツールのコピーをダウンロードし、管理対象のファイルツリー内でストレージと使用を管理します。これにより、ホストマシンとローカル ユーザー(インストールされている言語のバージョンを含む)が分離されます。
- ソース ID: 密閉ビルドシステムは、 入力の同一性を確保しようとします。Git などのコード リポジトリは、一意のハッシュコードでコード変更のセットを識別します。密閉ビルドシステムはこのハッシュを使用して、ビルドの入力に対する変更を識別します。
特典
密閉ビルドの主なメリットは次のとおりです。
- 速度: アクションの出力はキャッシュに保存できるため、入力が変更されない限り、アクションを再度 実行する必要はありません。
- 並列実行: 指定された入力と出力に対して、ビルドシステムは すべてのアクションのグラフを構築して、効率的かつ並列 実行を計算できます。ビルドシステムはルールを読み込み、アクション グラフとハッシュ入力を計算してキャッシュを検索します。
- 複数のビルド: 同じ マシンで複数の密閉ビルドをビルドできます。各ビルドでは異なるツールとバージョンが使用されます。
- 再現性: 密閉ビルドは、ビルドを生成した正確な条件がわかっているため、トラブルシューティングに適しています。
非密閉性の特定
Bazel への切り替えを準備している場合は、既存のビルドの密閉性を事前に改善しておくと、移行が容易になります。ビルドで非密閉性の一般的な原因は次のとおりです。
.mkファイルでの任意の処理- ファイルを非決定的に作成するアクションまたはツール(通常はビルド ID またはタイムスタンプを含む)
- ホスト間で異なるシステム バイナリ(
/usr/binバイナリ、絶対パス、ネイティブ C++ ルールの自動構成用のシステム C++ コンパイラなど) - ビルド中にソースツリーに書き込む。これにより、同じソースツリーを別のターゲットに使用できなくなります。最初のビルドはソースツリーに書き込み、ターゲット A のソースツリーを修正します。その後、ターゲット B のビルドを試行すると失敗する可能性があります。
非密閉ビルドのトラブルシューティング
ローカル実行から開始すると、ローカル キャッシュ ヒットに影響する問題によって非密閉アクションが明らかになります。
- null の順次ビルドを確認する:
makeを実行してビルドが成功した場合、ビルドを再度実行してもターゲットは再ビルドされません。各ビルドステップを 2 回実行するか、異なるシステムで実行して、ファイル コンテンツのハッシュを比較して異なる結果が得られた場合、ビルドは再現できません。 - さまざまなクライアント マシンからローカル キャッシュ ヒットをデバッグする手順を実行して、クライアント環境がアクションに漏洩するケースを確実にキャッチします。
- チェックアウトされたソースツリーとホストツールの明示的なリストのみを含む Docker コンテナ内でビルドを実行します。ビルドの破損とエラー メッセージによって、暗黙的なシステム依存関係がキャッチされます。
- リモート実行ルールを使用して、密閉性の問題を検出して修正します。
- ビルド内のアクションはステートフルで、ビルドや出力に影響する可能性があるため、アクションごとに厳格なサンドボックス を有効にします。
- ワークスペース ルール
を使用すると、デベロッパーは外部ワークスペースに依存関係を追加できますが、プロセス内で任意の処理を行うのに十分な機能があります。Bazel コマンドに
--experimental_workspace_rules_log_file=PATHフラグを追加すると、Bazel ワークスペース ルールで非密閉アクションのログを取得できます。
Bazel での密閉性
他のプロジェクトが Bazel で密閉 ビルドを使用して成功した方法について詳しくは、BazelCon の次のトークをご覧ください。
- Building Real-time Systems with Bazel(SpaceX)
- Bazel Remote Execution and Remote Caching(Uber and TwoSigma)
- Faster Builds With Remote Execution and Caching
- Fusing Bazel: Faster Incremental Builds
- Remote Execution vs Local Execution
- Improving the Usability of Remote Caching(IBM)
- Building Self Driving Cars with Bazel(BMW)
- Building Self Driving Cars with Bazel + Q&A(GM Cruise)