正在部署規則

回報問題 查看來源 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

本頁面適用於打算向他人提供規則的規則撰寫者。

建議您從範本存放區開始建立新的規則集: 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
  • 存放區說明:Go rules for Bazel
  • 存放區標記:golangbazel
  • README.md 標題:Go 規則 (適用於 Bazel) (請注意 https://bazel.build 的連結,可將不熟悉 Bazel 的使用者導向正確位置)

規則可依語言 (例如 Scala)、執行階段平台 (例如 Android) 或架構 (例如 Spring) 分組。

存放區內容

每個規則存放區都應採用特定版面配置,方便使用者快速瞭解新規則。

舉例來說,假設您要為 (虛構的) 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

在專案的 WORKSPACE 中,您應定義使用者用來參照規則的名稱。如果規則屬於 bazelbuild 機構,就必須使用 rules_<lang> (例如 rules_mockascript)。否則,您應該將存放區命名為 <org>_rules_<lang> (例如 build_stack_rules_proto)。如果您認為規則應遵循 bazelbuild 機構的規則慣例,請在 GitHub 上發起討論串。

在以下各節中,假設存放區屬於 bazelbuild 機構。

workspace(name = "rules_mockascript")

README

頂層應包含 README,其中 (至少) 應包含使用者需要複製並貼到 WORKSPACE 檔案中的內容,才能使用規則。一般來說,這會是 http_archive 指向 GitHub 版本的指標,以及下載/設定規則所需任何工具的巨集呼叫。舉例來說,如果是 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 檔案中使用這些限制,執行平台專屬邏輯 (例如使用 selects)。透過自訂限制,您可以定義整個 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 巨集,用來註冊這些工具鍊。這樣一來,使用者就能決定省略先前的巨集並手動控管依附元件,同時仍可註冊工具鍊。

因此,請在 <LANG>/repositories.bzl 檔案中新增名為 rules_<LANG>_toolchainsWORKSPACE 巨集。

請注意,為了在分析階段解析工具鍊,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/ 目錄,瞭解規則的幾種基本用法。

CI/CD

許多規則集都使用 GitHub Actions。請參閱 rules-template repo 中使用的設定,這些設定是透過 bazel-contrib 機構代管的「可重複使用的工作流程」簡化而來。ci.yaml 會對每個 PR 和 main 提交執行測試,而每當您將標記推送至存放區時,release.yaml 就會執行測試。 詳情請參閱規則範本存放區中的註解。

如果您的存放區位於 bazelbuild 機構下,可以要求將存放區新增ci.bazel.build

說明文件

如需如何註解規則,以便自動產生說明文件,請參閱 Stardoc 說明文件

rules-template docs/ 資料夾:簡單確保 docs/ 資料夾中的 Markdown 內容在 Starlark 檔案更新時,一律為最新版本。

常見問題

為什麼我們無法將規則新增至主要的 Bazel GitHub 存放區?

我們希望盡可能將規則與 Bazel 版本脫鉤。這樣一來,個別規則的擁有者就更清楚,可減輕 Bazel 開發人員的負擔。對使用者而言,規則分離後,修改、升級、降級及更換規則會更加容易。相較於 Bazel,貢獻規則的負擔較輕 (視規則而定),包括對應 GitHub 存放區的完整提交存取權。取得 Bazel 本身的提交存取權,是更複雜的程序。

缺點是使用者必須完成較為複雜的一次性安裝程序:他們必須將規則複製並貼到 WORKSPACE 檔案中,如上方的 README.md 部分所示。

我們過去將所有規則都放在 Bazel 存放區 (位於 //tools/build_rules//tools/build_defs 下方)。我們目前仍有幾項規則放在該處,但正努力將其餘規則移出。