使用巨集建立自訂動詞

回報問題查看原始碼。。。。夜間。。。。 7.3 。。 7.2 。。 7.1 。。 7.0 。 6.5 。。

與 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 指令。