Interaksi sehari-hari dengan Bazel terutama terjadi melalui beberapa perintah:
build
, test
, dan run
. Namun, terkadang hal ini dapat terasa terbatas: Anda mungkin
ingin mendorong paket ke repositori, memublikasikan dokumentasi untuk pengguna akhir, atau
men-deploy aplikasi dengan Kubernetes. Namun, Bazel tidak memiliki perintah publish
atau
deploy
– di mana tindakan ini cocok?
Perintah run bazel
Fokus Bazel pada hermetisitas, reproduksi, dan inkrementalitas berarti
perintah build
dan test
tidak membantu tugas di atas. Tindakan ini
dapat berjalan di sandbox, dengan akses jaringan terbatas, dan tidak dijamin akan
dijalankan ulang dengan setiap bazel build
.
Sebagai gantinya, andalkan bazel run
: mesin pekerja untuk tugas yang ingin Anda berikan
efek samping. Pengguna Bazel terbiasa dengan aturan yang membuat file yang dapat dieksekusi, dan
penulis aturan dapat mengikuti kumpulan pola umum untuk memperluasnya ke
"kata kerja kustom".
Di dunia nyata: rules_k8s
Misalnya, pertimbangkan rules_k8s
,
aturan Kubernetes untuk Bazel. Misalkan Anda memiliki target berikut:
# BUILD file in //application/k8s
k8s_object(
name = "staging",
kind = "deployment",
cluster = "testing",
template = "deployment.yaml",
)
Aturan k8s_object
mem-build
file YAML Kubernetes standar saat bazel build
digunakan pada target
staging
. Namun, target tambahan juga dibuat oleh makro k8s_object
dengan nama seperti staging.apply
dan :staging.delete
. Skrip build ini
dibuat untuk melakukan tindakan tersebut, dan saat dijalankan dengan bazel run
staging.apply
, skrip ini berperilaku seperti perintah bazel k8s-apply
atau bazel
k8s-delete
kita sendiri.
Contoh lain: ts_api_guardian_test
Pola ini juga dapat dilihat di project Angular. Makro ts_api_guardian_test
menghasilkan dua target. Yang pertama adalah target nodejs_test
standar yang membandingkan
beberapa output yang dihasilkan dengan file "emas" (yaitu, file yang berisi
output yang diharapkan). Fungsi ini dapat dibangun dan dijalankan dengan pemanggilan bazel
test
normal. Di angular-cli
, Anda dapat menjalankan satu target
tersebut
dengan bazel test //etc/api:angular_devkit_core_api
.
Seiring waktu, file emas ini mungkin perlu diperbarui untuk alasan yang sah.
Memperbarui ini secara manual akan melelahkan dan rentan error, sehingga makro ini juga menyediakan
target nodejs_binary
yang memperbarui file emas, bukan membandingkannya. Secara efektif, skrip pengujian yang sama dapat ditulis untuk dijalankan dalam mode "verifikasi"
atau "setujui", berdasarkan cara skrip tersebut dipanggil. Ini mengikuti pola yang sama
yang sudah Anda pelajari: tidak ada perintah bazel test-accept
native, tetapi
efek yang sama dapat dicapai dengan
bazel run //etc/api:angular_devkit_core_api.accept
.
Pola ini bisa sangat ampuh, dan ternyata menjadi sangat umum setelah Anda belajar mengenalinya.
Menyesuaikan aturan Anda sendiri
Makro adalah inti dari pola ini. Makro digunakan seperti aturan, tetapi dapat membuat beberapa target. Biasanya, target akan membuat target dengan nama yang ditentukan yang melakukan tindakan build utama: mungkin target tersebut mem-build biner normal, image Docker, atau arsip kode sumber. Dalam pola ini, target tambahan dibuat untuk menghasilkan skrip yang melakukan efek samping berdasarkan output target utama, seperti memublikasikan biner yang dihasilkan atau memperbarui output pengujian yang diharapkan.
Untuk mengilustrasikannya, gabungkan aturan imajiner yang membuat situs dengan Sphinx dengan makro untuk membuat target tambahan yang memungkinkan pengguna memublikasikannya saat siap. Pertimbangkan aturan yang ada berikut untuk membuat situs dengan Sphinx:
_sphinx_site = rule(
implementation = _sphinx_impl,
attrs = {"srcs": attr.label_list(allow_files = [".rst"])},
)
Selanjutnya, pertimbangkan aturan seperti berikut, yang membuat skrip yang, saat dijalankan, memublikasikan halaman yang dihasilkan:
_sphinx_publisher = rule(
implementation = _publish_impl,
attrs = {
"site": attr.label(),
"_publisher": attr.label(
default = "//internal/sphinx:publisher",
executable = True,
),
},
executable = True,
)
Terakhir, tentukan makro berikut untuk membuat target untuk kedua aturan di atas secara bersamaan:
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)
Di file BUILD
, gunakan makro seolah-olah makro baru saja membuat target
utama:
sphinx_site(
name = "docs",
srcs = ["index.md", "providers.md"],
)
Dalam contoh ini, target "docs" dibuat, seolah-olah makro adalah
satu aturan Bazel standar. Saat di-build, aturan akan menghasilkan beberapa konfigurasi
dan menjalankan Sphinx untuk menghasilkan situs HTML, yang siap untuk pemeriksaan manual. Namun, target "docs.publish" tambahan juga akan dibuat, yang akan membuat skrip untuk memublikasikan situs. Setelah memeriksa output target utama, Anda dapat
menggunakan bazel run :docs.publish
untuk memublikasikannya agar dapat dinikmati publik, seperti
perintah bazel publish
fiktif.
Tampilan penerapan aturan _sphinx_publisher
mungkin tidak langsung terlihat. Sering kali, tindakan seperti ini menulis skrip shell peluncur.
Metode ini biasanya melibatkan penggunaan
ctx.actions.expand_template
untuk menulis skrip shell yang sangat sederhana, dalam hal ini memanggil biner penayang
dengan jalur ke output target utama. Dengan cara ini, implementasi
penayang dapat tetap bersifat umum, aturan _sphinx_site
hanya dapat menghasilkan
HTML, dan skrip kecil ini adalah satu-satunya yang diperlukan untuk menggabungkan keduanya
secara bersamaan.
Di rules_k8s
, inilah yang dilakukan .apply
:
expand_template
menulis skrip Bash yang sangat sederhana, berdasarkan
apply.sh.tpl
,
yang menjalankan kubectl
dengan output target utama. Skrip ini kemudian dapat
di-build dan dijalankan dengan bazel run :staging.apply
, yang secara efektif menyediakan
perintah k8s-apply
untuk target k8s_object
.