WORKSPACE ルールでの非密閉動作の検出

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

以下の説明において、ホストマシンは Bazel が実行されるマシンです。

リモート実行を使用する場合、実際のビルドやテストのステップは 実行されず、リモート実行に送信される ありませんただし、Workspace のルールの解決に関する手順は、 作成されます。ワークスペースのルールでアクセスに関する情報と 使用すると、ビルドがクラッシュする可能性が高く、 環境間の非互換性の問題が起きます

リモート サーバー向けの Bazel ルール適用の一環として 実行するにはそのようなワークスペース ルールを 修正しますこのページでは、問題がある可能性のあるワークスペースを見つける方法について説明します 使用することもできます。

非密閉ルールの検索

Workspace ルールを使用すると、デベロッパーは依存関係を追加できる 外部ワークスペースに備わっていますが、十分なリソースを備えており、 発生します。関連するすべてのコマンドはローカルで実行され、 非密閉性の原因となる可能性があります。通常、非密閉動作は、 Google Cloud の repository_ctx: 操作が可能 関連付けられています

Bazel 0.18 以降では、密閉されていない可能性がある フラグ --experimental_workspace_rules_log_file=[PATH] を追加してアクションを Bazel コマンドを作成します。ここで、[PATH] はログが保存されるファイル名です。 作成されます。

注意事項:

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

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

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

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

  1. bazel clean --expunge を実行します。このコマンドを実行すると、ローカル キャッシュと キャッシュ内のリポジトリを削除して、すべての初期化が再実行されるようにします。

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

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

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

    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: ホスト環境で任意のコマンドを実行します。確認 これにより、ホスト環境に依存関係が生じる可能性があります。

  • download、download_and_extract: 密閉型のビルドを行うには、 SHA256 が指定されている

  • file、template: これはそれ自体は非密閉ではありませんが、メカニズムの可能性があります。 を使用して、ホスト環境への依存関係をリポジトリに導入します。 入力元を把握することと、入力ではないことを確認する 依存します。

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

  • symlink: 通常、これは安全ですが、レッドフラグを探してください。シンボリック リンクは、 絶対パスにファイルを保存すると、実行時に問題が発生します。 支援しますシンボリック リンクがホストマシンのプロパティに基づいて作成されている場合 問題になります

  • which: 通常、ホストにインストールされているプログラムの確認に問題があります ワーカーの構成が異なる可能性があるためです