密閉型

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

概要

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

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

再現性の重要な側面は次の 2 つです。

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

利点

再現性のあるビルドの主なメリットは次のとおりです。

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

再現性のない動作の特定

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

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

再現性のないビルドのトラブルシューティング

ローカル実行から開始して、ローカル キャッシュのヒットに影響する問題から、 再現性のないアクションを特定します。

Bazel での再現性

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