このページは、ルールを他のユーザーが利用できるようにすることを計画しているルール作成者を対象としています 。
テンプレート リポジトリ（ https://github.com/bazel-contrib/rules-template ）から新しいルールセットを開始することをおすすめします。このテンプレートは以下の推奨事項に準拠しており、API ドキュメントの生成が含まれています。 また、ルールセットの配布を簡単にするために CI/CD パイプラインを設定します。
ホスティングと命名規則
新しいルールは、組織の独自の 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 など）、フレームワーク（Spring など）でグループ化できます。
リポジトリのコンテンツ
ユーザーが新しいルールをすばやく 理解できるように、すべてのルール リポジトリに特定のレイアウトを設定する必要があります。
たとえば、（架空の）
mockascript 言語の新しいルールを作成する場合、ルール リポジトリの構造は次のようになります。
/
LICENSE
README
MODULE.bazel
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
MODULE.bazel
プロジェクトの MODULE.bazel で、ユーザーがルールを参照するために使用する名前を定義する必要があります
。ルールが
bazelbuild 組織に属している場合は、
rules_<lang>（rules_mockascript など）を使用する必要があります。それ以外の場合は、
リポジトリに <org>_rules_<lang>（build_stack_rules_proto など）という名前を付けます。ルールが
bazelbuild 組織のルールの命名規則に従う必要があると思われる場合は、
GitHub
でスレッドを開始してください。
以降のセクションでは、リポジトリが bazelbuild 組織に属していることを前提としています。
module(name = "rules_mockascript")
README
最上位レベルには、ルールセットの簡単な説明
と API ユーザーが想定すべき内容を含む README が必要です。
ルール
多くの場合、リポジトリには複数のルールが用意されています。言語で名前を付けたディレクトリを作成し、すべてのルールをエクスポートするエントリ ポイント 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 ファイルで実行するために
使用します（たとえば、select の使用など）。
カスタム制約を使用すると、Bazel エコシステム全体が使用する言語を定義できます。
Runfiles ライブラリ
ルールで runfiles にアクセスするための標準ライブラリが提供されている場合は、
//<LANG>/runfiles（//<LANG>/runfiles:runfiles の略）にあるライブラリ ターゲットの形式にする必要があります。データ
依存関係にアクセスする必要があるユーザー ターゲットは、通常、このターゲットを deps 属性に追加します。
リポジトリ ルール
依存関係
ルールに外部依存関係がある場合は、 MODULE.bazel ファイルで指定する必要があります。
ツールチェーンの登録
ルールでツールチェーンを登録することもできます。これも MODULE.bazel ファイルで指定できます。
分析フェーズでツールチェーンを解決するには、Bazel で登録されているすべての toolchain ターゲットを
分析する必要があります。Bazel will not need to
属性で参照されるすべてのターゲットを分析する必要はありません。toolchain.toolchainツールチェーンを登録するためにリポジトリで複雑な計算を行う必要がある場合は、toolchain ターゲットを含むリポジトリを <LANG>_toolchain ターゲットを含むリポジトリから分割することを検討してください。前者は常に取得されますが、
後者はユーザーが実際に <LANG> コードをビルドする必要がある場合にのみ取得されます。
リリース スニペット
リリース アナウンスで、ユーザーがコピーして貼り付けることができるスニペットを
MODULE.bazel ファイルに提供します。このスニペットは一般的に次のようになります。
bazel_dep(name = "rules_<LANG>", version = "<VERSION>")
テスト
ルールが想定どおりに機能していることを確認するテストが必要です。これは、ルールの対象となる言語の標準の場所、または最上位レベルの
tests/ディレクトリに配置できます。
例（省略可）
ルールを使用できる基本的な方法をいくつか示す examples/ ディレクトリがあると便利です。
CI/CD
多くのルールセットで GitHub Actions が使用されています。ルールテンプレート リポジトリで使用されている構成をご覧ください。これは、bazel-contrib
組織でホストされている「再利用可能なワークフロー」を使用して簡略化されています。ci.yaml は各 PR と main コミットでテストを実行し、release.yaml はリポジトリにタグを push するたびに実行されます。
詳細については、ルールテンプレート リポジトリのコメントをご覧ください。
リポジトリが bazelbuild 組織にある場合は、 ci.bazel.build への追加をci.bazel.buildできます。
ドキュメント
ドキュメントを自動的に生成できるようにルールにコメントを追加する方法については、Stardoc のドキュメントをご覧ください。
よくある質問
ルールをメインの Bazel GitHub リポジトリに追加できないのはなぜですか？
ルールを Bazel リリースからできるだけ切り離したいと考えています。個々のルールの所有者が明確になり、Bazel デベロッパーの負担が軽減されます。ユーザーにとっては、 切り離すことでルールの変更、アップグレード、ダウングレード、置き換えが容易になります。 ルールへの投稿は、Bazel への投稿よりも軽量にできます。 ルールによっては、対応する GitHub リポジトリへの完全な送信アクセス権が付与されます。Bazel 自体への送信アクセス権を取得するには、はるかに複雑なプロセスが必要です 。
欠点は、ユーザー向けのインストール プロセスが複雑になることです。
ルールセットへの依存関係を MODULE.bazel ファイルに追加する必要があります。
以前は、すべてのルールが Bazel リポジトリ（
//tools/build_rules または //tools/build_defs）にありました。現在もいくつかのルール
がありますが、残りのルールを移動する作業を進めています。