このページは、ルールを利用できるようにすることを予定しているルール作成者向けです できます。
テンプレート リポジトリから新しいルールセットを開始することをおすすめします。 https://github.com/bazel-contrib/rules-template このテンプレートは、以下の推奨事項に従っており、API ドキュメントの生成が含まれています。 CI/CD パイプラインを設定して、ルールセットの配布を簡素化します。
ホスティング ルールと命名規則
新しいルールは、組織の GitHub リポジトリに配置する必要があります。 GitHub でスレッドを開始する ルールが bazelbuild に属すると思われる場合 できます。
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 など）、ランタイム プラットフォーム、 フレームワーク（Spring など）の 3 つのコンポーネントがあります。
リポジトリのコンテンツ
ユーザーがルールをすぐに実行できるように、すべてのルール リポジトリに特定のレイアウトを用意する 理解しやすくなっています。
たとえば、（仮説の）ルールに関する新しいルールを
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 など）。恐れ入りますが、
GitHub でスレッドを開始する
ルールの規約に従う必要がある場合は、
bazelbuild 組織。
以降のセクションでは、リポジトリが bazelbuild 組織を使用します。
module(name = "rules_mockascript")
README
トップレベルに、簡単な説明を含む README があるはずです。
API のユーザーが期待する内容です。
ルール
多くの場合、リポジトリによって複数のルールが提供されます。作成:
言語で指定された名前のディレクトリがあり、エントリ ポイントとなる 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 ファイルでプラットフォーム固有のロジックを実行するために使用します（たとえば、
selects を使用します）。
カスタム制約を使用すると、Bazel エコシステム全体で使える言語を定義できます。
が話します。
Runfiles ライブラリ
ルールでランファイルにアクセスするための標準ライブラリが提供される場合は、それを
//<LANG>/runfiles にあるライブラリ ターゲットの形式（略称
///<LANG>/runfiles:runfiles）。データにアクセスする必要があるユーザー ターゲット
依存関係は通常、このターゲットを deps 属性に追加します。
リポジトリ ルール
依存関係
ルールに外部との依存関係がある場合は、 コピーします。
ツールチェーンの登録
ルールでツールチェーンを登録することもできます。ツールチェーン MODULE.bazel ファイル
分析フェーズでツールチェーンを解決するには、Bazel が次のことを行う必要があります。
登録されているすべての toolchain ターゲットを分析します。Bazel は、24 時間以内に
toolchain.toolchain 属性で参照されるすべてのターゲットを分析します。順序がある場合
ツールチェーンを登録するには、ツールチェーンで複雑な計算を
toolchain ターゲットでリポジトリを分割することを検討してください。
<LANG>_toolchain 個のターゲットを含むリポジトリ。以前のクエリは常に取得され、
後者は、ユーザーが実際に <LANG> コードをビルドする必要がある場合にのみフェッチされます。
リリース スニペット
リリースのお知らせで、ユーザーがコピー&ペーストできるスニペットを提供します。
MODULE.bazel ファイルに含める必要があります。このスニペットは通常、次のようになります。
bazel_dep(name = "rules_<LANG>", version = "<VERSION>")
テスト
ルールが想定どおりに機能していることを確認するテストが必要です。この
ルールの対象言語の標準的な場所か、
tests/ ディレクトリにあります。
例（省略可）
ユーザーにいくつかの情報を表示する examples/ ディレクトリがあると、ユーザーにとって便利です
基本的な使用方法について説明します。
CI / CD
多くのルールセットで GitHub Actions が使用されています。rules-template リポジトリで使用されている構成を確認します。これは、「再利用可能なワークフロー」を使用して簡素化されています。bazel-contrib でホストされた
orgci.yaml は PR と main の commit ごとにテストを実行します。release.yaml は、リポジトリにタグを push するたびに実行されます。
詳細については、rules-template リポジトリ内のコメントをご覧ください。
リポジトリが bazelbuild 組織の下にある場合は、 追加するよう依頼して ci.bazel.build に追加します。
ドキュメント
詳しくは、Stardoc のドキュメント ドキュメントを生成できるようにルールにコメントを付ける方法 自動的に適用されます。
rules-template docs/ フォルダ
docs/ フォルダ内の Markdown コンテンツを常に最新状態に維持する簡単な方法を示す図
Starlark ファイルの更新時に行われます。
よくある質問
メインの Bazel GitHub リポジトリにルールを追加できないのはなぜですか？
Google では、できる限り Bazel リリースからルールを分離したいと考えています。明確である Bazel 開発者の負荷を軽減します。ユーザーにとって 分離することで、ルールの変更、アップグレード、ダウングレード、置き換えが容易になります。 ルールへの貢献は、Bazel への貢献よりも軽量です。 （対応するオブジェクトへの完全な送信アクセス権を含む） GitHub リポジトリ。Bazel 自体への送信アクセス権を取得する作業は、 プロセスです
この方法の短所は、ユーザーにとって 1 回限りのインストール プロセスが複雑になることです。
MODULE.bazel ファイルでルールセットへの依存関係を追加する必要があります。
以前は、すべてのルールが Bazel リポジトリ（
//tools/build_rules や //tools/build_defs など）。まだいくつかのルールがあります
残りのルールは削除する予定です。