本页面适用于计划向他人提供规则的规则编写者。
托管和命名规则
新规则应放入贵组织名下的 GitHub 代码库中。如果您认为自己的规则属于 bazelbuild 组织，请与 bazel-dev 邮寄列表联系。
Bazel 规则的代码库名称已按以下格式标准化：$ORGANIZATION/rules_$NAME。请参阅 GitHub 上的示例。为保持一致性，您在发布 Bazel 规则时必须遵循此相同格式。
请务必使用描述性的 GitHub 代码库说明和 README.md 标题，例如：
- 代码库名称：
bazelbuild/rules_go - 代码库说明：适用于 Bazel 的 Go 规则
- 代码库标记：
golang、bazel README.md标题：适用于 Bazel 的 Go 规则（请注意指向 https://bazel.build 的链接，该链接会将不熟悉 Bazel 的用户引导至正确位置）
规则可以按语言（如 Scala）或平台（如 Android）进行分组。
代码库内容
每个规则库都应采用特定布局，以便用户快速了解新规则。
例如，在为 (make-believe) mockascript 语言编写新规则时，规则仓库将具有以下结构：
/
LICENSE
README
WORKSPACE
mockascript/
constraints/
BUILD
runfiles/
BUILD
runfiles.mocs
BUILD
defs.bzl
tests/
BUILD
some_test.sh
another_test.py
examples/
BUILD
bin.mocs
lib.mocs
test.mocs
工作区
在项目的 WORKSPACE 中，您应定义用户将用于引用您的规则的名称。如果您的规则属于 bazelbuild 组织，则必须使用 rules_<lang>（例如 rules_mockascript）。否则，您应将代码库命名为 <org>_rules_<lang>（例如 build_stack_rules_proto）。如果您认为自己的规则应遵循 bazelbuild 组织中的规则惯例，请与 bazel-dev 邮寄名单联系。
在以下部分中，假设代码库属于 bazelbuild 组织。
workspace(name = "rules_mockascript")
自述文件
顶层应该有一个 README，其中至少应包含用户需要将哪些内容复制并粘贴到 WORKSPACE 文件中才能使用您的规则。一般来说，这将是一个指向您的 GitHub 版本的 http_archive，以及一个用于下载/配置规则所需工具的宏调用。例如，对于 Go 规则，该规则如下所示：
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_go",
urls = ["https://github.com/bazelbuild/rules_go/releases/download/0.18.5/rules_go-0.18.5.tar.gz"],
sha256 = "a82a352bffae6bee4e95f68a8d80a70e87f42c4741e6a448bec11998fcc82329",
)
load("@rules_go//go:deps.bzl", "go_rules_dependencies", "go_register_toolchains")
go_rules_dependencies()
go_register_toolchains()
如果您的规则依赖于其他代码库的规则，请在规则文档中指定这一点（例如，请参阅依赖于 Sass 规则的 Skydoc 规则），并提供一个用于下载所有依赖项的 WORKSPACE 宏（请参阅上文中的 rules_go）。
规则
通常，您的代码库会提供多条规则。创建一个以该语言命名的目录，并提供一个入口点，即导出所有规则的 defs.bzl 文件（还应包含 BUILD 文件，使该目录是一个软件包）。对于 rules_mockascript，这意味着其中会有一个名为 mockascript 的目录，以及一个 BUILD 文件和一个 defs.bzl 文件：
/
mockascript/
BUILD
defs.bzl
限制条件
如果您的规则定义了工具链规则，您可能需要定义自定义 constraint_setting 和/或 constraint_value。将它们放入 //<LANG>/constraints 软件包中。您的目录结构将如下所示：
/
mockascript/
constraints/
BUILD
BUILD
defs.bzl
请参阅 github.com/bazelbuild/platforms，了解最佳实践并查看现有的约束条件，如果您的约束条件不依赖于语言，不妨考虑在该处贡献您的约束条件。请注意引入自定义限制条件，您的规则的所有用户都将使用这些规则在其 BUILD 文件中执行平台特定的逻辑（例如，使用选择）。借助自定义限制条件，您可以定义整个 Bazel 生态系统将使用的语言。
Runfiles 库
如果您的规则提供用于访问 runfile 的标准库，则它应采用位于 //<LANG>/runfiles（//<LANG>/runfiles:runfiles 的缩写）的库目标的形式。需要访问其数据依赖项的用户目标通常会将此目标添加到其 deps 属性中。
代码库规则
依赖项
您的规则可能存在外部依赖项。为了简化依赖于规则的操作，请提供 WORKSPACE 宏来声明对这些外部依赖项的依赖关系。请勿在其中声明测试的依赖项，只声明规则正常运行所需的依赖项。将开发依赖项放入 WORKSPACE 文件中。
创建一个名为 <LANG>/repositories.bzl 的文件，并提供一个名为 rules_<LANG>_dependencies 的入口点宏。我们的目录将如下所示：
/
mockascript/
constraints/
BUILD
BUILD
defs.bzl
repositories.bzl
注册工具链
您的规则可能还会注册工具链。请提供一个单独的 WORKSPACE 宏来注册这些工具链。这样一来，用户就可以决定省略前面的宏并手动控制依赖项，同时仍允许注册工具链。
因此，请将名为 rules_<LANG>_toolchains 的 WORKSPACE 宏添加到 <LANG>/repositories.bzl 文件中。
请注意，为了在分析阶段解析工具链，Bazel 需要分析已注册的所有 toolchain 目标。Bazel 不需要分析 toolchain.toolchain 属性引用的所有目标。如需注册工具链，您需要在代码库中执行复杂的计算，请考虑从具有 <LANG>_toolchain 目标的代码库中拆分具有 toolchain 目标的代码库。前者始终会被提取，而后者仅在用户确实需要构建 <LANG> 代码时才会提取。
版本摘要
在版本公告中提供一个代码段，以供用户复制并粘贴到 WORKSPACE 文件中。此代码段通常如下所示：
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_<LANG>",
urls = ["<url_to_the_release.zip"],
sha256 = "4242424242",
)
load("@rules_<LANG>//<LANG>:repositories.bzl", "rules_<LANG>_dependencies", "rules_<LANG>_toolchains")
rules_<LANG>_dependencies()
rules_<LANG>_toolchains()
测试
应通过测试来验证规则是否按预期运行。该目录可以位于规则所用语言的标准位置，也可以位于顶层的 tests/ 目录。
示例（可选）
拥有一个 examples/ 目录，向用户显示一些可以使用规则的基本方法，这对用户来说非常实用。
测试
按照使用入门文档中的说明设置 Travis。然后，将 .travis.yml 文件添加到代码库中，其中包含以下内容：
dist: xenial # Ubuntu 16.04
# On trusty (or later) images, the Bazel apt repository can be used.
addons:
apt:
sources:
- sourceline: 'deb [arch=amd64] http://storage.googleapis.com/bazel-apt stable jdk1.8'
key_url: 'https://bazel.build/bazel-release.pub.gpg'
packages:
- bazel
script:
- bazel build //...
- bazel test //...
如果您的代码库位于 bazelbuild 组织下，您可以要求将其添加到 ci.bazel.build。
文档
如需了解如何为规则添加注释以便自动生成文档，请参阅 Stardoc 文档。
常见问题解答
为什么我们无法将规则添加到主要的 Bazel GitHub 代码库？
我们希望尽可能将规则与 Bazel 版本解耦。这样可以更清楚地了解各个规则的所有者，从而减轻 Bazel 开发者的负担。对于用户而言，解耦可让他们更轻松地修改、升级、降级和替换规则。贡献规则可能比贡献 Bazel 更轻松（具体取决于规则），包括对相应 GitHub 代码库的完全提交权限。获得对 Bazel 的提交访问权限本身是一个更加复杂的过程。
缺点是，用户的一次性安装流程会更复杂：他们必须将规则复制并粘贴到 WORKSPACE 文件中，如上文的 README.md 部分所示。
我们以前将所有规则都放在 Bazel 代码库中（位于 //tools/build_rules 或 //tools/build_defs 下）。我们仍在该代码库中保留一些规则，但正在努力将其余规则移出。