このページは、ルールを他のユーザーに公開することを計画しているルール作成者を対象としています。
テンプレート リポジトリ(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 ルール(Bazel に詳しくないユーザーを適切な場所に誘導する https://bazel.build へのリンクに注意)
ルールは、言語(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
ファイルでプラットフォーム固有のロジックを実行するためにカスタム制約を使用することに注意してください(選択を使用するなど)。カスタム制約を使用すると、Bazel エコシステム全体で使用する言語を定義できます。
Runfiles ライブラリ
ルールでランファイルにアクセスするための標準ライブラリが提供されている場合、それは //<LANG>/runfiles
(//<LANG>/runfiles:runfiles
の略)にあるライブラリ ターゲットの形式になります。データ依存関係にアクセスする必要があるユーザー ターゲットは、通常、このターゲットを deps
属性に追加します。
リポジトリ ルール
依存関係
ルールに外部依存関係がある場合は、MODULE.bazel ファイルで指定する必要があります。
ツールチェーンの登録
ルールでツールチェーンを登録することもできます。ツールチェーンは MODULE.bazel ファイルで指定することもできます。
分析フェーズでツールチェーンを解決するには、登録されているすべての toolchain
ターゲットを Bazel で分析する必要があります。Bazel は、toolchain.toolchain
属性で参照されるすべてのターゲットを分析する必要がなくなります。ツールチェーンを登録するためにリポジトリで複雑な計算を行う必要がある場合は、toolchain
ターゲットを含むリポジトリを <LANG>_toolchain
ターゲットを含むリポジトリから分割することを検討してください。前者は常に取得され、後者はユーザーが実際に <LANG>
コードをビルドする必要がある場合にのみ取得されます。
リリース スニペット
リリースのお知らせで、ユーザーが MODULE.bazel
ファイルにコピー&ペーストできるスニペットを提供します。このスニペットは一般的に次のようになります。
bazel_dep(name = "rules_<LANG>", version = "<VERSION>")
テスト
ルールが想定どおりに機能していることを検証するテストが必要です。これは、ルールの対象となる言語の標準の場所か、最上位の tests/
ディレクトリのいずれかに配置できます。
例(省略可)
ユーザーがルールを使用できる基本的な方法をいくつか示す examples/
ディレクトリがあると便利です。
CI / CD
多くのルールセットで GitHub Actions が使用されています。bazel-contrib 組織でホストされている「再利用可能なワークフロー」を使用して簡略化された rules-template リポジトリで使用されている構成をご覧ください。ci.yaml
は各 PR と main
コミットでテストを実行し、release.yaml
はリポジトリにタグを push するたびに実行されます。詳細については、rules-template リポジトリのコメントをご覧ください。
リポジトリが bazelbuild 組織にある場合は、ci.bazel.build への追加をリクエストできます。
ドキュメント
ドキュメントを自動的に生成できるようにルールにコメントを追加する方法については、Stardoc のドキュメントをご覧ください。
rules-template docs/ フォルダには、Starlark ファイルが更新されたときに docs/
フォルダ内の Markdown コンテンツを常に最新の状態に保つ簡単な方法が示されています。
よくある質問
ルールをメインの Bazel GitHub リポジトリに追加できないのはなぜですか?
ルールを Bazel リリースからできるだけ切り離したいと考えています。個々のルールを誰が所有しているかが明確になり、Bazel デベロッパーの負担が軽減されます。ユーザーにとって、ルールを切り離すことで、ルールの変更、アップグレード、ダウングレード、置換が容易になります。ルールへの投稿は、対応する GitHub リポジトリへの完全な送信アクセス権限を含め、ルールによっては Bazel への投稿よりも軽量になる可能性があります。Bazel 自体への送信アクセス権を取得するには、はるかに複雑なプロセスが必要です。
デメリットは、ユーザー向けの 1 回限りのインストール プロセスが複雑になることです。ユーザーは、MODULE.bazel
ファイルでルールセットの依存関係を追加する必要があります。
以前は、すべてのルールが Bazel リポジトリ(//tools/build_rules
または //tools/build_defs
の下)にありました。現在もいくつかのルールが残っていますが、残りのルールを移動する作業を進めています。