与 Bazel 的日常互动主要通过几个命令进行：build、test 和 run。不过，有时这些命令可能会受到限制：您可能需要将软件包推送到代码库、为最终用户发布文档，或使用 Kubernetes 部署应用。但 Bazel 没有 publish 或 deploy 命令，那么这些操作应该如何进行？
bazel run 命令
Bazel 专注于密封性、可重现性和增量性，这意味着 build 和 test 命令对上述任务没有帮助。这些操作可能会在沙盒中运行，网络访问权限有限，并且不能保证每次 bazel build 都会重新运行。
相反，请依赖于 bazel run：它是您想要产生副作用的任务的主力。 Bazel 用户习惯于创建可执行文件的规则，规则作者可以遵循一组通用模式将其扩展到“自定义动词”。
实际应用：rules_k8s
例如，考虑 rules_k8s，
它是 Bazel 的 Kubernetes 规则。假设您有以下目标：
# BUILD file in //application/k8s
k8s_object(
name = "staging",
kind = "deployment",
cluster = "testing",
template = "deployment.yaml",
)
当对 staging
目标使用 bazel build 时，k8s_object 规则 会构建
标准的 Kubernetes YAML 文件。不过，其他目标也是由 k8s_object 宏创建的，名称类似于 staging.apply 和 :staging.delete。这些构建脚本用于执行这些操作，并且在通过 bazel run
staging.apply 执行时，这些脚本的行为类似于我们自己的 bazel k8s-apply 或 bazel
k8s-delete 命令。
另一个示例：ts_api_guardian_test
此模式也可以在 Angular 项目中看到。
ts_api_guardian_test 宏
会生成两个目标。第一个是标准的 nodejs_test 目标，它会将一些生成的输出与“黄金”文件（即包含预期输出的文件）进行比较。这可以使用正常的 bazel
test 调用进行构建和运行。在 angular-cli 中，您可以运行 其中一个
目标
，使用 bazel test //etc/api:angular_devkit_core_api。
随着时间的推移，出于正当理由，可能需要更新此黄金文件。
手动更新此文件既繁琐又容易出错，因此此宏还提供了一个 nodejs_binary 目标，用于更新黄金文件，而不是与黄金文件进行比较。实际上，可以编写相同的测试脚本以在“验证”或“接受”模式下运行，具体取决于其调用方式。这遵循了您已经了解的相同模式：没有原生 bazel test-accept 命令，但可以使用 bazel run //etc/api:angular_devkit_core_api.accept 实现相同的效果。
这种模式非常强大，而且一旦您学会识别它，就会发现它非常常见。
调整您自己的规则
宏是此模式的核心。宏的使用方式与规则类似，但它们可以创建多个目标。通常，它们会创建一个具有指定名称的目标，该目标执行主要构建操作：或许是构建普通二进制文件、Docker 映像或源代码归档。在此模式中，系统会创建其他目标，以生成基于主要目标输出执行副作用的脚本，例如发布生成的二进制文件或更新预期测试输出。
为了说明这一点，请使用宏封装一个假想规则，该规则使用 Sphinx生成网站，以创建其他 目标，让用户可以在准备就绪后发布该网站。请考虑以下使用 Sphinx 生成网站的现有规则：
_sphinx_site = rule(
implementation = _sphinx_impl,
attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)
接下来，考虑如下规则，该规则构建一个脚本，该脚本在运行时发布生成的网页：
_sphinx_publisher = rule(
implementation = _publish_impl,
attrs = {
"site": attr.label(),
"_publisher": attr.label(
default = "//internal/sphinx:publisher",
executable = True,
),
},
executable = True,
)
最后，定义以下符号宏（在 Bazel 8 或更高版本中提供），以便为上述两个规则一起创建目标：
def _sphinx_site_impl(name, visibility, srcs, **kwargs):
# This creates the primary target, producing the Sphinx-generated HTML. We
# set `visibility = visibility` to make it visible to callers of the
# macro.
_sphinx_site(name = name, visibility = visibility, srcs = srcs, **kwargs)
# This creates the secondary target, which produces a script for publishing
# the site generated above. We don't want it to be visible to callers of
# our macro, so we omit visibility for it.
_sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)
sphinx_site = macro(
implementation = _sphinx_site_impl,
attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
# Inherit common attributes like tags and testonly
inherit_attrs = "common",
)
或者，如果您需要支持 Bazel 8 之前的 Bazel 版本，则应改为定义旧版宏：
def sphinx_site(name, srcs = [], **kwargs):
# This creates the primary target, producing the Sphinx-generated HTML.
_sphinx_site(name = name, srcs = srcs, **kwargs)
# This creates the secondary target, which produces a script for publishing
# the site generated above.
_sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)
在 BUILD 文件中，使用宏，就好像它只是创建主要目标一样：
sphinx_site(
name = "docs",
srcs = ["index.md", "providers.md"],
)
在此示例中，系统会创建一个“docs”目标，就好像该宏是标准的单个 Bazel 规则一样。构建后，该规则会生成一些配置并运行 Sphinx 以生成 HTML 网站，以便进行手动检查。不过，系统还会创建一个额外的“docs.publish”目标，用于构建发布网站的脚本。检查主要目标的输出后，您可以使用 bazel run :docs.publish 将其发布以供公开使用，就像假想的 bazel publish 命令一样。
_sphinx_publisher 规则的实现方式并不明显。通常，此类操作会编写启动器 shell 脚本。 此方法通常涉及使用
ctx.actions.expand_template
编写非常简单的 Shell 脚本，在本例中，该脚本会使用主要目标的输出路径调用发布方二进制文件。这样，发布者实现可以保持通用性，_sphinx_site 规则可以只生成 HTML，而这个小脚本是将其组合在一起所必需的全部内容。
在 rules_k8s 中，这确实是 .apply 的作用：
expand_template
根据
apply.sh.tpl编写一个非常简单的 Bash 脚本，
该脚本使用 kubectl 的输出运行主要目标。然后，可以使用 bazel run :staging.apply 构建和运行此脚本，从而有效地为 k8s_object 目标提供 k8s-apply 命令。