本页面适用于计划向他人提供其规则的规则编写者。
托管和命名规则
新规则应会归入贵组织名下的 GitHub 代码库。 如果您认为自己的规则属于 bazelbuild 组织，可以在 GitHub 上发起线程。
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 组织中的规则，请在 GitHub 上发起会话。
在以下部分中，假设代码库属于 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 库
如果您的规则提供用于访问运行文件的标准库，则应采用位于 //<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 属性引用的所有目标。如需注册工具链，您需要在代码库中执行复杂的计算，请考虑将具有 toolchain 目标的代码库与具有 <LANG>_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 下。我们还有一些规则，但我们正在努力移除其余规则。