永久性工作器可让您的构建更快。如果您的 build 中有重复操作，这些操作的启动成本很高，或者会受益于交叉操作缓存，那么您可能需要实现自己的永久性工作器来执行这些操作。
Bazel 服务器使用 stdin/stdout 与工作器通信。它支持使用协议缓冲区或 JSON 字符串。
worker 实现包含两个部分：
使 worker
持久性工作器需要满足以下几项要求：
- 它从其
stdin中读取 WorkRequests。 - 它会将 WorkResponses（且仅
WorkResponse）写入其stdout。 - 它接受
--persistent_worker标志。封装容器必须识别--persistent_worker命令行标记，并且仅在传递该标记时使其自身持久化，否则它必须进行单次编译并退出。
如果您的程序满足这些要求，您就可以将其用作持久性工作器！
工作请求
WorkRequest 包含 worker 的参数列表、表示 worker 可以访问的输入的路径-摘要对列表（未强制执行，但您可以使用此信息进行缓存）以及请求 ID（对于单工工作器，此 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 请求额外的调试输出。输出什么以及如何输出完全由 worker 决定。值越高，表示输出越详细。将 --worker_verbose 标志传递给 Bazel 会将 verbosity 字段设置为 10，但您可以针对不同的输出手动使用更小或更大的值。
可选的 sandbox_dir 字段仅供支持多路复用沙盒的工作器使用。
工作响应
WorkResponse 包含一个请求 ID、一个零或非零退出代码，以及一个用于描述处理或执行请求过程中遇到的任何错误的输出字符串。output 字段包含简短说明；完整的日志可能会写入工作器的 stderr。由于工作器只能将 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 大于零的请求。系统会按顺序发送 Singleplex 请求，例如，如果服务器在收到响应之前未发送其他请求（取消请求除外，请参阅下文）。
Notes
- 每个协议缓冲区都以
varint格式的长度开头（请参阅MessageLite.writeDelimitedTo()）。 - JSON 请求和响应的前面没有大小指示符。
- JSON 请求保持与 protobuf 相同的结构，但使用标准 JSON 并对所有字段名称使用驼峰式大小写。
- 为了保持与 protobuf 相同的向后和向前兼容性属性，JSON 工作器必须容忍这些消息中的未知字段，并对缺失值使用 protobuf 默认值。
- Bazel 将请求存储为 protobuf，并使用 protobuf 的 JSON 格式将其转换为 JSON。
取消
工作器可以选择性地允许在工作请求完成之前将其取消。这在与动态执行相关时特别有用，因为动态执行中，本地执行可能会经常被较快的远程执行中断。若要允许取消，请将 supports-worker-cancellation: 1 添加到 execution-requirements 字段（见下文），并设置 --experimental_worker_cancellation 标志。
取消请求是设置了 cancel 字段的 WorkRequest（同样，取消响应是设置了 was_cancelled 字段的 WorkResponse）。取消请求或取消响应中必须存在的唯一另一个字段是 request_id，用于指示要取消哪个请求。对于单工工作器，request_id 字段将为 0；对于多路复用工作器，request_id 字段将是之前发送的 WorkRequest 的非 0。服务器可能会针对工作器已响应的请求发送取消请求，在这种情况下，必须忽略取消请求。
每条非取消 WorkRequest 消息都必须只回复一次，无论它是否被取消都是如此。服务器发送取消请求后，工作器可能会返回 WorkResponse（设置 request_id 并将 was_cancelled 字段设置为 true）。系统也可以发送常规 WorkResponse，但会忽略 output 和 exit_code 字段。
针对 WorkRequest 发送响应后，工作器不得触碰其工作目录中的文件。服务器可以随意清理文件，包括临时文件。
制定使用工作器的规则
您还需要创建一条规则，生成工作器要执行的操作。创建使用工作器的 Starlark 规则与创建任何其他规则一样。
此外，该规则需要包含对 worker 本身的引用，并且其生成的操作有一些要求。
提及 worker
使用工作器的规则需要包含一个引用工作器本身的字段，因此您需要创建 \*\_binary 规则的实例来定义工作器。如果您的工作器名为 MyWorker.Java，那么这可能是关联的规则：
java_binary(
name = "worker",
srcs = ["MyWorker.Java"],
)
这将创建“工作器”标签，该标签指的是工作器二进制文件。然后，您将定义一条使用工作器的规则。此规则应定义一个引用工作器二进制文件的属性。
如果您构建的工作器二进制文件位于名为“work”的软件包（位于 build 的顶层）中，则属性定义可能是：
"worker": attr.label(
default = Label("//work:worker"),
executable = True,
cfg = "exec",
)
cfg = "exec" 表示应将 worker 构建为在执行平台（而不是目标平台）上运行（即，工作器在构建期间用作工具）。
工作操作要求
使用工作器的规则创建了工作器要执行的操作。这些操作有一些要求。
"arguments" 字段。该函数需要一个字符串列表，但最后一个字符串除外，其所有字符串均为在启动时传递给 worker 的参数。“实参”列表中的最后一个元素是
flag-file（带 @ 前缀）参数。工作器会按 WorkRequest 读取指定标志文件中的参数。您的规则可以将工作器的非启动参数写入此标志文件。"execution-requirements" 字段，它采用包含
"supports-workers" : "1"和/或"supports-multiplex-workers" : "1"的字典。发送到工作器的所有操作都需要“参数”和“执行要求”字段。此外，应由 JSON 工作器执行的操作需要在执行要求字段中包含
"requires-worker-protocol" : "json"。"requires-worker-protocol" : "proto"也是一项有效的执行要求，但 proto 工作器不需要它，因为它们是默认设置。您还可以在执行要求中设置
worker-key-mnemonic。如果要将可执行文件重复用于多种操作类型，并希望区分此工作器的操作，这样做可能很有用。操作过程中生成的临时文件应保存到 worker 的目录中。这会启用沙盒。
假设规则定义具有上述“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"]
)
如需查看其他示例，请参阅实现永久性工作器。
示例
除了用于我们的集成测试的示例 JSON 工作器之外，Bazel 代码库还使用 Java 编译器工作器。
通过传入正确的回调，您可以使用其基架将任何基于 Java 的工具放入工作器。
如需查看使用工作器的规则示例，请查看 Bazel 的工作器集成测试。
外部贡献者以多种语言实现了 worker；请参阅 Bazel 永久性工作器的 Polyglot 实现。您可以在 GitHub 上找到更多示例！