使用巨集建立自訂動詞

7.3 · 7.2 · 7.1 · 7.0 · 6.5

與 Bazel 的日常互動主要是透過幾個指令:buildtestrun。不過,有時這些功能可能會讓您感到受限:您可能想將套件推送至存放區、為使用者發布文件,或透過 Kubernetes 部署應用程式。但 Bazel 沒有 publishdeploy 指令,這些動作要如何執行?

bazel run 指令

Bazel 著重在歷史性、可重現性和成效增幅,因此 buildtest 指令不適用於上述工作。這些動作可能會在網路存取權有限的沙箱中執行,而且不保證每次都會在每個 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",
)

staging 目標使用 bazel build 時,k8s_object 規則會建構標準 Kubernetes YAML 檔案。不過,其他目標也會由 k8s_object 巨集建立,名稱為 staging.apply:staging.delete。這些建構指令碼可用來執行這些動作,當使用 bazel run staging.apply 執行時,這些指令碼的行為就像我們專屬的 bazel k8s-applybazel 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 目標,用於更新黃金檔案,而不是進行比較。實際上,相同的測試指令碼可根據叫用方式,以「驗證」或「接受」模式來編寫執行。這符合您所學的模式:沒有原生 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"],
)

在這個範例中,系統會建立「docs」目標,就像巨集是標準的單一 Bazel 規則一樣。建立完成後,規則會產生一些設定並執行 Sphinx 以產生 HTML 網站,以供手動檢查。不過,系統也會建立額外的「docs.publish」目標,用於建構用於發布網站的指令碼。檢查主要目標的輸出內容後,您可以使用 bazel run :docs.publish 將其發布供大眾使用,就像虛構的 bazel publish 指令一樣。

_sphinx_publisher 規則的實作方式可能不太明顯。這類操作通常會寫入啟動器 Shell 指令碼。這個方法通常會使用 ctx.actions.expand_template 編寫非常簡單的 Shell 指令碼,在本例中,您可以使用主要目標輸出的路徑叫用發布者二進位檔。這樣一來,發布器實作項目可以保持通用,_sphinx_site 規則只會產生 HTML,而這個小腳本就是結合這兩者的必要條件。

rules_k8s 中,.apply 確實會執行以下操作:expand_template 會根據 apply.sh.tpl 編寫非常簡單的 Bash 指令碼,並使用主要目標的輸出內容執行 kubectl。如此一來,您就能使用 bazel run :staging.apply 建構及執行這個指令碼,有效為 k8s_object 目標提供 k8s-apply 指令。