密閉型

Nightly · 9.1 · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 8.1

このページでは、密閉性、密閉ビルドを使用するメリット、ビルドで非密閉動作を特定するための戦略について説明します。

概要

密閉ビルドシステムは、同じ入力ソースコードとプロダクト構成が与えられた場合、ホストシステムの変更からビルドを分離することで、常に同じ出力を返します。

ビルドを分離するために、密閉ビルドはローカルまたはリモートのホストマシンにインストールされているライブラリやその他のソフトウェアに影響を受けません。コンパイラなどのビルドツールや、ライブラリなどの依存関係の特定のバージョンに依存します。これにより、ビルド環境の外部のサービスに依存しないため、ビルドプロセスが自己完結型になります。

密閉性の重要な側面は次の 2 つです。

  • 分離: 密閉ビルドシステムは、ツールをソースコードとして扱います。ツールのコピーをダウンロードし、マネージド ファイル ツリー内でストレージと使用を管理します。これにより、言語のインストール バージョンなど、ホストマシンとローカル ユーザーが分離されます。
  • ソース ID: 密閉ビルドシステムは、 入力の同一性を確保しようとします。Git などのコード リポジトリは、一意のハッシュコードでコード変更のセットを識別します。密閉ビルドシステムはこのハッシュを使用して、ビルドの入力に対する変更を識別します。

特典

密閉ビルドの主なメリットは次のとおりです。

  • 速度: アクションの出力はキャッシュに保存できるため、入力が変更されない限り、アクションを再度 実行する必要はありません。
  • 並列実行: 指定された入力と出力に対して、ビルドシステムは すべてのアクションのグラフを構築して、効率的かつ並列 実行を計算できます。ビルドシステムはルールを読み込み、アクション グラフとハッシュ入力を計算してキャッシュを検索します。
  • 複数のビルド: 同じ マシンで複数の密閉ビルドをビルドできます。各ビルドでは、異なるツールとバージョンを使用します。
  • 再現性: 密閉ビルドは、ビルドを生成した正確な条件がわかっているため、トラブルシューティングに適しています。

非密閉性の特定

Bazel への切り替えを準備している場合は、既存のビルドの密閉性を事前に改善しておくと、移行が容易になります。ビルドの非密閉性の一般的な原因は次のとおりです。

  • .mk ファイルでの任意の処理
  • 通常、ビルド ID またはタイムスタンプを含む、ファイルを非決定的に作成するアクションまたはツール
  • ホスト間で異なるシステム バイナリ（/usr/bin バイナリ、絶対パス、ネイティブ C++ ルールの自動構成用のシステム C++ コンパイラなど）
  • ビルド中にソースツリーに書き込む。これにより、同じソースツリーを別のターゲットに使用できなくなります。最初のビルドはソースツリーに書き込み、ターゲット A のソースツリーを修正します。その後、ターゲット B のビルドを試行すると失敗する可能性があります。

非密閉ビルドのトラブルシューティング

ローカル実行から開始すると、ローカル キャッシュ ヒットに影響する問題によって非密閉アクションが明らかになります。

Bazel の密閉性

他のプロジェクトが Bazel で密閉 ビルドを使用して成功した方法について詳しくは、次の BazelCon の講演をご覧ください。