BazelCon 2022 は、11 月 16 ~ 17 日にニューヨークとオンラインで開催されます。
今すぐご登録ください。

WORKSPACE ルールで非密閉型動作を見つける

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

以下において、ホストマシンとは、Bazel が実行されるマシンを意味します。

リモート実行を使用する場合、実際のビルドやテストの手順はホストマシンでは実行されず、リモート実行システムに送信されます。ただし、ワークスペース ルールの解決に関連する手順はホストマシン上で行われます。ワークスペース ルールが実行中にホストマシンに関する情報にアクセスする場合、環境間の非互換性が原因でビルドが失敗する可能性があります。

リモート実行用に Bazel ルールを適応させるの一環として、こうしたワークスペース ルールを見つけて修正する必要があります。このページでは、ワークスペースログを使用して、問題のある可能性があるワークスペース ルールを検索する方法について説明します。

非密閉型ルールの検索

ワークスペース ルールでは、開発者は外部ワークスペースに依存関係を追加できますが、この役割は十分大きく、処理中に任意の処理を行うことができます。すべての関連コマンドはローカルで行われ、非密閉の原因になる可能性があります。通常、非密閉型動作は、repository_ctx によって導入され、ホストマシンとの対話が可能になります。

Bazel 0.18 以降では、Bazel コマンドにフラグ --experimental_workspace_rules_log_file=[PATH] を追加することで、非密閉型のアクションのログを取得できます。[PATH] は、ログが作成される際のファイル名です。

注意事項:

  • このログは、実行の際にイベントをキャプチャします。一部のステップがキャッシュに保存されると、ログには表示されないため、完全な結果を得るには、事前に bazel clean --expunge を実行することを忘れないでください。

  • 関数が再実行されることもあります。その場合、関連するイベントがログに何度も表示されます。

  • 現在、Workspace ルールでは Starlark イベントのみがログに記録されます。

ワークスペースの初期化中に実行された内容を確認するには:

  1. bazel clean --expunge を実行します。このコマンドにより、ローカル キャッシュとキャッシュに保存されたリポジトリがクリーンアップされ、すべての初期化が再実行されます。

  2. Bazel コマンドに --experimental_workspace_rules_log_file=/tmp/workspacelog を追加してビルドを実行します。

    これにより、WorkspaceEvent タイプのメッセージを一覧表示するバイナリ proto ファイルが生成されます。

  3. 次のコマンドを使用して Bazel ソースコードをダウンロードし、Bazel フォルダに移動します。ワークスペース パーサーを使用してワークスペース ログを解析できるようにするには、ソースコードが必要です。

    git clone https://github.com/bazelbuild/bazel.git
    cd bazel
    
  4. Bazel ソースコード リポジトリで、ワークスペースのログ全体をテキストに変換します。

    bazel build src/tools/workspacelog:parser
    bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog > /tmp/workspacelog.txt
    
  5. 非常に冗長な出力であり、組み込みの Bazel ルールからの出力が含まれている場合があります。

    特定のルールを出力から除外するには、--exclude_rule オプションを使用します。 例:

    bazel build src/tools/workspacelog:parser
    bazel-bin/src/tools/workspacelog/parser --log_path=/tmp/workspacelog \
        --exclude_rule "//external:local_config_cc" \
        --exclude_rule "//external:dep" > /tmp/workspacelog.txt
    
  6. /tmp/workspacelog.txt を開き、安全でないオペレーションを確認します。

ログは WorkspaceEvent メッセージで構成され、repository_ctx に対して実行される、非密閉型のアクションの概要を示します。

非密閉型としてハイライト表示されている操作は次のとおりです。

  • execute: ホスト環境で任意のコマンドを実行します。これらによってホスト環境に依存関係が生じる可能性があるかどうかを確認します。

  • downloaddownload_and_extract: 密閉型のビルドにするには、sha256 を指定します。

  • filetemplate: これ自体は密閉型ではありませんが、ホスト環境への依存関係をリポジトリに取り込むメカニズムの場合があります。入力元を把握し、ホスト環境に依存しないようにします。

  • os: これ自体は密閉型ではありませんが、ホスト環境への依存関係を取得する簡単な方法です。密閉型ビルドは通常、これを呼びません。使用が密閉型かどうかを評価する際は、ワーカーではなくホスト上で実行されていることに注意してください。一般的に、リモートビルドでは、ホストから環境の詳細を取得しないでください。

  • symlink: 通常は安全ですが、赤色のフラグを探します。リポジトリ外のリンクや絶対パスへのシンボリック リンクがあると、リモート ワーカーで問題が発生します。シンボリック リンクがホストマシンのプロパティに基づいて作成されている場合、問題が生じる可能性があります。

  • which: 通常、ホストにインストールされているプログラムをチェックすることは、ワーカーの構成が異なる可能性があるため問題となります。