Bazel のロックファイル機能を使用すると、プロジェクトに必要なソフトウェア ライブラリやパッケージの特定のバージョンや依存関係を記録できます。これは、モジュールの解決と拡張機能の評価の結果を保存することで実現されます。ロックファイルは再現可能なビルドを促進し、一貫性のある開発環境を確保します。また、プロジェクトの依存関係に変更がない場合に Bazel が解決プロセスをスキップできるようにすることで、ビルドの効率が向上します。さらに、ロックファイルは外部ライブラリの予期しない更新や互換性を破る変更を防ぐことで安定性を向上させ、バグが発生するリスクを軽減します。
ロックファイルの生成
ロックファイルは、ワークスペースのルートの下に MODULE.bazel.lock
という名前で生成されます。ビルドプロセス中、特にモジュールの解決と拡張機能の評価の後に作成または更新されます。ロックファイルは、MODULE ファイル、フラグ、オーバーライド、その他の関連情報など、プロジェクトの現在の状態をキャプチャします。重要なのは、現在のビルド呼び出しに含まれている依存関係のみが含まれていることです。
プロジェクト内で依存関係に影響する変更が発生すると、ロックファイルは新しい状態を反映するように自動的に更新されます。これにより、ロックファイルは現在のビルドに必要な特定の依存関係のセットにフォーカスされたままとなり、プロジェクトの解決済みの依存関係を正確に表現できます。
ロックファイルの使用
ロックファイルはフラグ --lockfile_mode
で制御して、プロジェクトの状態がロックファイルと異なる場合の Bazel の動作をカスタマイズできます。使用可能なモードは次のとおりです。
update
(デフォルト): プロジェクトの状態がロックファイルと一致する場合、解決結果がロックファイルからすぐに返されます。それ以外の場合は、解決が実行され、現在の状態を反映するようにロックファイルが更新されます。error
: プロジェクトの状態がロックファイルと一致する場合、解決結果がロックファイルから返されます。それ以外の場合、Bazel はプロジェクトとロックファイルの違いを示すエラーをスローします。このモードは、プロジェクトの依存関係が変更されず、差分がエラーとして扱われるようにする場合に特に便利です。off
: ロックファイルはまったくチェックされません。
ロックファイルのメリット
ロックファイルにはいくつかの利点があります。また、さまざまな方法で利用できます。
再現可能なビルド。ロックファイルでは、ソフトウェア ライブラリの特定のバージョンや依存関係をキャプチャすることで、さまざまな環境や時間の経過に伴ってビルドを再現できます。デベロッパーは、プロジェクトをビルドする際に、一貫性があり予測可能な結果を利用できます。
効率的な解決策のスキップ。前回のビルド以降にプロジェクトの依存関係に変更がない場合、ロックファイルにより Bazel は解決プロセスをスキップできます。これにより、特に解決に時間がかかるシナリオで、ビルドの効率が大幅に向上します。
安定性とリスクの軽減。ロックファイルは、外部ライブラリの予期しない更新や互換性を破る変更を防止することで、安定性を維持します。依存関係を特定のバージョンにロックすることで、互換性のない更新やテストされていない更新が原因でバグが発生するリスクが軽減されます。
ロックファイルの内容
ロックファイルには、プロジェクトの状態が変化したかどうかを判断するために必要なすべての情報が含まれています。現在の状態でプロジェクトをビルドした結果も含まれます。ロックファイルは、次の 2 つの主要部分で構成されています。
- モジュール解像度の入力(
moduleFileHash
、flags
、localOverrideHashes
など)と、解像度の出力(moduleDepGraph
)。 - 各モジュール拡張機能のロックファイルには、影響を受ける入力(
transitiveDigest
で表される)と、その拡張機能の実行による出力(generatedRepoSpecs
と呼ばれます)が含まれています。
以下に、ロックファイルの構造の例と各セクションの説明を示します。
{
"lockFileVersion": 1,
"moduleFileHash": "b0f47b98a67ee15f9.......8dff8721c66b721e370",
"flags": {
"cmdRegistries": [
"https://bcr.bazel.build/"
],
"cmdModuleOverrides": {},
"allowedYankedVersions": [],
"envVarAllowedYankedVersions": "",
"ignoreDevDependency": false,
"directDependenciesMode": "WARNING",
"compatibilityMode": "ERROR"
},
"localOverrideHashes": {
"bazel_tools": "b5ae1fa37632140aff8.......15c6fe84a1231d6af9"
},
"moduleDepGraph": {
"<root>": {
"name": "",
"version": "",
"executionPlatformsToRegister": [],
"toolchainsToRegister": [],
"extensionUsages": [
{
"extensionBzlFile": "extension.bzl",
"extensionName": "lockfile_ext"
}
],
...
}
},
"moduleExtensions": {
"//:extension.bzl%lockfile_ext": {
"transitiveDigest": "oWDzxG/aLnyY6Ubrfy....+Jp6maQvEPxn0pBM=",
"generatedRepoSpecs": {
"hello": {
"bzlFile": "@@//:extension.bzl",
...
}
}
}
}
}
モジュール・ファイル・ハッシュ
moduleFileHash
は、MODULE.bazel
ファイル コンテンツのハッシュを表します。このファイルに変更が発生した場合、ハッシュ値は異なります。
フラグ
Flags
オブジェクトには、解決結果に影響を与える可能性のあるすべてのフラグが格納されます。
ローカル オーバーライド ハッシュ
ルート モジュールに local_path_overrides
が含まれている場合、このセクションでは MODULE.bazel
ファイルのハッシュがローカル リポジトリに保存されます。この依存関係の変更を追跡できます。
モジュールの依存関係グラフ
moduleDepGraph
は、上記の入力を使用した解決プロセスの結果を表します。プロジェクトの実行に必要なすべてのモジュールの依存関係グラフを作成します。
モジュール拡張機能
moduleExtensions
セクションは、現在の呼び出しで使用されている拡張機能、または以前に呼び出された拡張機能のみを含むマップで、使用されなくなった拡張機能は除外されます。つまり、依存関係グラフ全体で使用されなくなった拡張機能は、moduleExtensions
マップから削除されます。
このマップの各エントリは、使用された拡張機能に対応し、そのファイルと名前で識別されます。各エントリに対応する値には、その拡張機能に関連付けられた関連情報が含まれています。
transitiveDigest
: 拡張機能実装とその推移的な .bzl ファイルのダイジェスト。generatedRepoSpecs
: 現在の入力でその拡張機能を実行した結果。
拡張機能の結果に影響を与える可能性のある追加の要因は、その使用状況です。拡張機能の現在の状態とロックファイル内の状態を比較する際に、ロックファイルに保存されませんが、使用状況が考慮されます。
ベスト プラクティス
ロックファイル機能のメリットを最大化するには、次のベスト プラクティスを検討してください。
定期的にロックファイルを更新して、プロジェクトの依存関係や構成の変更を反映します。これにより、以降のビルドが最新かつ正確な依存関係のセットに基づくようになります。
ロックファイルをバージョン管理に含めてコラボレーションを促進し、すべてのチームメンバーが同じロックファイルにアクセスできるようにします。これにより、プロジェクト全体で一貫性のある開発環境が促進されます。
これらのベスト プラクティスに従うことで、Bazel のロックファイル機能を効果的に利用し、より効率的で信頼性が高く、コラボレーション指向のソフトウェア開発ワークフローを実現できます。