本页面适用于计划向他人提供规则的规则编写者。
托管和命名规则
新规则应放入贵组织名下的 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）进行分组。
代码库内容
每个规则库都应采用特定布局，以便用户快速了解新规则。
例如，为（假想的）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 属性引用的所有目标。如果您需要在代码库中执行复杂的计算来注册工具链，请考虑将包含 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。然后，将 .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 下）。我们仍在该代码库中保留一些规则，但正在努力将其余规则移出。