使用巨集建立自訂動詞

與 Bazel 的日常互動主要是透過幾個指令進行： build、test和run。然而，您可能會遇到以下問題： 您可能會想將套件推送至存放區、為使用者發布說明文件 運用 Kubernetes 部署應用程式但 Bazel 沒有 publish deploy 指令 – 這些動作的顯示位置為何？

bazel run 指令

Bazel 著重在遺傳性、可重現性和成效增幅 build 和 test 指令對上述工作沒有幫助。這些動作 可以在網路存取有限的沙箱中執行， 每次 bazel build 重新執行。

請改用 bazel run，也就是您「想」執行的工作該工作。 副作用Bazel 使用者習慣建立執行檔的規則 規則作者可遵循一組通用模式，將這層關係延伸到 「自訂動詞」

對外：rules_k8s

例如 rules_k8s Bazel 的 Kubernetes 規則假設您的目標如下：

# BUILD file in //application/k8s
k8s_object(
    name = "staging",
    kind = "deployment",
    cluster = "testing",
    template = "deployment.yaml",
)

k8s_object 規則會建構 staging 上使用 bazel build 時的標準 Kubernetes YAML 檔案 目標。不過，k8s_object 也會建立其他目標 巨集，例如 staging.apply 和 :staging.delete 等名稱。這些版本 指令碼執行這些動作；當使用 bazel run staging.apply 執行時，這些動作的行為就像我們專屬的 bazel k8s-apply 或 bazel k8s-delete 指令。

其他範例：ts_api_guardian_test

您也可以在 Angular 專案中查看這個模式。 ts_api_guardian_test 巨集 會產生兩個目標第一個是標準 nodejs_test 目標，用於比較 某些生成的輸出內容也就是含有 預期的輸出內容)。透過一般 bazel test 叫用，即可建構及執行這項功能。在 angular-cli 中，您可以執行 目標 搭配 bazel test //etc/api:angular_devkit_core_api。

一段時間後，這個黃金檔案可能基於正當理由需要更新。 手動更新這個程序既繁瑣又容易出錯，因此這個巨集也提供 更新黃金檔案的 nodejs_binary 目標，而不是比較 互相對抗實際上，相同的測試指令碼可以直接在「verify」中執行 或「接受」並自動切換模式。也遵循相同的模式 您已瞭解：沒有原生 bazel test-accept 指令，但 也能達到相同效果 bazel run //etc/api:angular_devkit_core_api.accept。

這個模式的功能可能非常強大 辨識出來的方法

自行調整規則

巨集是這個模式的核心。巨集的用途類似 但可以建立多個指定目標他們通常會建立 目標為指定名稱，執行主要建構動作：或許 容器則會建構一般二進位檔、Docker 映像檔或原始碼封存檔於 因此會建立其他目標 例如發布主要目標的輸出內容 二進位檔，或更新預期的測試輸出內容。

為了方便說明，請包裝一個能產生一個網站的虛構規則， 將 Sphinx 與巨集搭配使用，以建立額外的 讓使用者在準備就緒時即可發布影片請考量下列要點 使用 Sphinx 產生網站的現有規則：

_sphinx_site = rule(
     implementation = _sphinx_impl,
     attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)

接著，請設想一個建立指令碼的規則，在執行時 發布產生的網頁：

_sphinx_publisher = rule(
    implementation = _publish_impl,
    attrs = {
        "site": attr.label(),
        "_publisher": attr.label(
            default = "//internal/sphinx:publisher",
            executable = True,
        ),
    },
    executable = True,
)

最後，請定義下列巨集，為上述兩個 整體有幾項規則

def sphinx_site(name, srcs = [], **kwargs):
    # This creates the primary target, producing the Sphinx-generated HTML.
    _sphinx_site(name = name, srcs = srcs, **kwargs)
    # This creates the secondary target, which produces a script for publishing
    # the site generated above.
    _sphinx_publisher(name = "%s.publish" % name, site = name, **kwargs)

在 BUILD 檔案中，使用巨集就如同建立主要巨集 目標：

sphinx_site(
    name = "docs",
    srcs = ["index.md", "providers.md"],
)

在這個範例中，「文件」就如同 標準、單一 Bazel 規則規則會在建構完成後產生一些設定 並執行 Sphinx 製作 HTML 網站以手動檢查。不過 額外的「docs.publish」也會建立相應的指令碼 或是發布網站檢查主要目標的輸出內容後 使用 bazel run :docs.publish 發布資訊供大眾使用，就像 虛構的 bazel publish 指令

如何立即瞭解 _sphinx_publisher 的實作方式 看起來會像這樣這類動作通常會編寫啟動器殼層指令碼。 這種方法通常需要使用 ctx.actions.expand_template敬上 編寫非常簡單的 shell 指令碼，本例是叫用發布商二進位檔 其中包含主要目標的輸出內容路徑如此一來 實作可以保持一般性，_sphinx_site 規則只需產生 若要結合這兩種程式碼 。

在 rules_k8s 中，這就是 .apply 的功用： expand_template敬上 編寫非常簡單的 Bash 指令碼 apply.sh.tpl, 這會以主要目標的輸出內容執行 kubectl。這個指令碼可以 然後透過 bazel run :staging.apply 建構及執行，有效提供 k8s_object 目標的 k8s-apply 指令。