永続ワーカーの作成

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

永続ワーカーを使用すると、ビルドを高速化できます。条件ビルド内で、起動コストが高いアクションを繰り返し実行したり、クロスアクションキャッシュのメリットを享受したい場合は、独自の永続ディスクをアクションを実行できます

Bazel サーバーは、stdin/stdout を使用してワーカーと通信します。これは、プロトコルバッファまたは JSON 文字列の使用がサポートされています。

ワーカーの実装は 2 つの部分に分かれています。

ワーカー。
ワーカーを使用するルール。

ワーカーの作成

永続ワーカーはいくつかの要件を満たします。

読みます。 WorkRequests stdin から。
書き込み WorkResponses （そして WorkResponse のみ）を stdout に追加します。
--persistent_worker フラグを受け入れます。ラッパーはデータを認識する --persistent_worker コマンドラインフラグを指定し、次の場合にのみ永続化します。渡されない場合、ワンショットコンパイルを実行して終了する必要があります。

プログラムがこれらの要件を満たしていれば、労働者！

処理リクエスト

WorkRequest には、ワーカーに対する引数のリスト、ワーカーがアクセスできる入力を表すパスとダイジェストのペア（これは必須ですが、この情報をキャッシュに使用できます。リクエスト ID（0）パフォーマンスが向上します

注: プロトコルバッファの仕様では「スネークケース」が使用されますが、(request_id), JSON プロトコルでは「キャメルケース」という（requestId）。このドキュメントではキャメルケースを使用していますこれは JSON の例で異なりますが、フィールドについて話すときは、構成されます。

{
  "arguments" : ["--some_argument"],
  "inputs" : [
    { "path": "/path/to/my/file/1", "digest": "fdk3e2ml23d"},
    { "path": "/path/to/my/file/2", "digest": "1fwqd4qdd" }
 ],
  "requestId" : 12
}

オプションの verbosity フィールドを使用して、追加のデバッグ出力をリクエストできます。割り当てることができます。何をどのように出力するかは、ワーカーによって異なります。高値を指定すると、出力が冗長になります。--worker_verbose フラグを Bazel で verbosity フィールドを 10 に設定しているが、小さい値も大きい値も使用可能出力の量を手動で調整します。

オプションの sandbox_dir フィールドは、サポートされているワーカーのみが多重サンドボックス化。

仕事用の回答

WorkResponse には、リクエスト ID、ゼロまたはゼロ以外の終了コード、処理中に発生したエラーを説明する出力文字列表示されます。output フィールドには簡単な説明が含まれます。完全なログはワーカーの stderr に書き込まれます。ワーカーは外部 IP アドレスから WorkResponses から stdout へ。ワーカーが stdout をリダイレクトするのが一般的です。ツールの stderr。

{
  "exitCode" : 1,
  "output" : "Action failed with the following message:\nCould not find input
    file \"/path/to/my/file/1\"",
  "requestId" : 12
}

protobuf の標準に従い、すべてのフィールドは省略可能です。ただし、Bazel では WorkRequest と対応する WorkResponse（同じリクエストを持つため）リクエスト ID がゼロ以外の場合は、そのリクエスト ID を指定する必要があります。有効な ID です WorkResponse。

{
  "requestId" : 12,
}

request_id が 0 の場合は、「シングルプレックス」を示します。このリクエストが他のリクエストと並行して処理できません。サーバーは特定のワーカーが、request_id 0 または request_id は 0 よりも大きくなります。シングルプレックスリクエストは、が次のサンプルリクエストを受け取るまで、サーバーは別のリクエストを送信しません。（キャンセルリクエストを除きます。以下を参照してください）。

注

各プロトコルバッファの先頭には、varint 形式の長さが付加されています（ MessageLite.writeDelimitedTo()。
JSON のリクエストとレスポンスの前にサイズインジケーターはありません。
JSON リクエストは protobuf と同じ構造を保持しますが、標準のすべてのフィールド名でキャメルケースを使用します。
下位互換性と上位互換性を維持するために、 JSON ワーカーはこれらのメッセージ内の不明なフィールドを許容する必要がある欠損値には protobuf のデフォルトを使用します。
Bazel はリクエストを protobuf として保存し、 protobuf の JSON 形式

キャンセル

ワーカーは、処理リクエストが完了前にキャンセルできるようにすることもできます。これは、ローカル環境で実行を行う場合に特に便利です。より高速なリモート実行によって定期的に実行を中断できます。許可する supports-worker-cancellation: 1 を execution-requirements フィールド（下記参照）に移動し、 --experimental_worker_cancellation フラグ。

キャンセルリクエストは、cancel フィールドが設定された WorkRequest です（同様に、キャンセルレスポンスは was_cancelled を含む WorkResponse です。設定されます。キャンセルリクエストまたはキャンセルに含める必要がある唯一のフィールドです。レスポンスは、キャンセルするリクエストを示す request_id です。request_id フィールドは、シングルプレックスワーカーの場合 0、または以前のワーカーの 0 以外の request_id になります。 Multiplex ワーカーに WorkRequest を送信しました。サーバーがキャンセルリクエストを送信する可能性があるワーカーがすでに応答しているリクエストの場合、キャンセルは無視する必要があります。

キャンセル以外の各 WorkRequest メッセージには、次のどちらかの場合に 1 回だけ応答する必要があります。キャンセルされたわけではありません。サーバーがキャンセルリクエストを送信すると、ワーカーは request_id を設定して WorkResponse を返し、was_cancelled を返すフィールドを true に設定します。通常の WorkResponse の送信も可能ですが、 output フィールドと exit_code フィールドは無視されます。

WorkRequest に対するレスポンスを送信したら、ワーカーは作成されます。サーバーでは自由にファイルをクリーンアップでき一時ファイルも含まれます。

ワーカーを使用するルールを作成する

また、ユーザーによって実行されるアクションを生成するルールもできます。ワーカーを使用する Starlark ルールの作成は、作成することもできます。

また、ワーカー自体への参照を含む必要があります。また、生成するアクションにはいくつかの要件があります。

ワーカーの参照

ワーカーを使用するルールには、ワーカーを参照するフィールドを含める必要があるそのため、\*\_binary ルールのインスタンスを作成して、判断できますワーカーが MyWorker.Java の場合、これは関連ルール:

java_binary(
    name = "worker",
    srcs = ["MyWorker.Java"],
)

これにより、「ワーカー」ワーカーバイナリを参照するラベルです。その後、ワーカーを使用するルールを定義します。このルールでは、作成する属性をワーカーバイナリを指します

ビルドしたワーカーバイナリが、一番上にある「work」という名前のパッケージにある場合は、場合、これは属性定義である可能性があります。

"worker": attr.label(
    default = Label("//work:worker"),
    executable = True,
    cfg = "exec",
)

cfg = "exec" は、ワーカーが実行プラットフォーム（つまり、Worker を使用して使用しないでください）。

作業アクションの要件

ワーカーを使用するルールによって、ワーカーが実行するアクションが作成されます。これらのいくつかの要件があります

"arguments" フィールドこれは文字列のリストを受け取ります。最後の文字列を除くすべての文字列をこれらは起動時にワーカーに渡される引数です。最後の要素は「arguments」list は flag-file（@ で始まる）引数です。ワーカーの読み取り指定されたフラグファイルの引数を WorkRequest 単位で取得します。お客様のワーカーの起動時以外の引数をこのフラグファイルに書き込むことができます。
"execution-requirements" フィールド "supports-workers" : "1"、"supports-multiplex-workers" : "1"、またはその両方です。

「引数」"execution-requirements"フィールドはすべてのアクションをワーカーに送信するよう設定できますまた組織が実行すべきアクションは JSON ワーカーは、変数名に "requires-worker-protocol" : "json" を [実行要件]フィールドに入力します"requires-worker-protocol" : "proto" もというのが有効な実行要件ですが、proto ワーカーでは必須ではありません。これらがデフォルトなので

また、実行要件で worker-key-mnemonic を設定することもできます。この実行可能ファイルを複数のアクションタイプで再利用する場合や、このワーカーによるアクションを区別できます
アクションの過程で生成された一時ファイルは、作業ディレクトリです。これにより、サンドボックス化が有効になります。

ルール定義が「worker」であると仮定属性に加えて、「srcs」に入力を表す「output」という属性出力を表す「args」ワーカーを表す属性 ctx.actions.run の呼び出しは次のようになります。

ctx.actions.run(
  inputs=ctx.files.srcs,
  outputs=[ctx.outputs.output],
  executable=ctx.executable.worker,
  mnemonic="someMnemonic",
  execution_requirements={
    "supports-workers" : "1",
    "requires-worker-protocol" : "json"},
  arguments=ctx.attr.args + ["@flagfile"]
 )

別の例については、永続ワーカーの実装。

例

Bazel コードベースでは、 Java コンパイラワーカーおよびサンプル JSON ワーカー統合テストで使われる

こちらのスキャフォールディング適切なコールバックを渡すことで、Java ベースのツールをワーカーにすることができます。

ワーカーを使用するルールの例については、Bazel のワーカー統合テストを実行します。

外部の貢献者は、さまざまな言語でワーカーを導入しています。CANNOT TRANSLATE 見て Bazel 永続ワーカーの多言語実装。 Google Chat では GitHub で他にも多くのサンプルがあります。