Codebase Bazel

Dokumen ini adalah deskripsi codebase dan struktur Bazel. Fitur ini dimaksudkan untuk orang yang bersedia berkontribusi pada Bazel, bukan untuk pengguna akhir.

Pengantar

Codebase Bazel berukuran besar (~350KLOC kode produksi dan ~260 KLOC kode pengujian) dan tidak ada yang memahami seluruh lanskap: semua orang mengetahui lembah tertentu dengan sangat baik, tetapi hanya sedikit yang mengetahui apa yang ada di atas bukit di setiap arah.

Agar orang-orang yang berada di tengah perjalanan tidak merasa berada di dalam hutan yang gelap dengan jalur yang mudah hilang, dokumen ini mencoba memberikan ringkasan codebase sehingga lebih mudah untuk memulai mengerjakannya.

Versi publik kode sumber Bazel tersedia di GitHub di github.com/bazelbuild/bazel. Ini bukan "sumber tepercaya"; ini berasal dari hierarki sumber internal Google yang berisi fungsi tambahan yang tidak berguna di luar Google. Tujuan jangka panjangnya adalah menjadikan GitHub sebagai sumber tepercaya.

Kontribusi diterima melalui mekanisme permintaan pull GitHub reguler, dan diimpor secara manual oleh Googler ke dalam hierarki sumber internal, lalu diekspor kembali ke GitHub.

Arsitektur klien/server

Sebagian besar Bazel berada dalam proses server yang tetap berada di RAM di antara build. Hal ini memungkinkan Bazel mempertahankan status di antara build.

Inilah sebabnya command line Bazel memiliki dua jenis opsi: startup dan perintah. Di command line seperti ini:

    bazel --host_jvm_args=-Xmx8G build -c opt //foo:bar

Beberapa opsi (--host_jvm_args=) berada sebelum nama perintah yang akan dijalankan dan beberapa berada setelahnya (-c opt); jenis pertama disebut "opsi startup" dan memengaruhi proses server secara keseluruhan, sedangkan jenis kedua, "opsi perintah", hanya memengaruhi satu perintah.

Setiap instance server memiliki satu ruang kerja terkait (kumpulan pohon sumber yang dikenal sebagai "repositori") dan setiap ruang kerja biasanya memiliki satu instance server aktif. Hal ini dapat diatasi dengan menentukan basis output kustom (lihat bagian "Tata letak direktori" untuk mengetahui informasi selengkapnya).

Bazel didistribusikan sebagai satu file ELF yang dapat dieksekusi yang juga merupakan file .zip yang valid. Saat Anda mengetik bazel, ELF yang dapat dieksekusi di atas yang diimplementasikan dalam C++ ("klien") akan mendapatkan kontrol. Tindakan ini menyiapkan proses server yang sesuai menggunakan langkah-langkah berikut:

1. Memeriksa apakah file tersebut telah diekstrak. Jika tidak, sistem akan melakukannya. Di sinilah implementasi server berasal.
2. Memeriksa apakah ada instance server aktif yang berfungsi: berjalan, memiliki opsi startup yang tepat, dan menggunakan direktori ruang kerja yang tepat. Fungsi ini menemukan server yang sedang berjalan dengan melihat direktori $OUTPUT_BASE/server tempat terdapat file kunci dengan port yang diproses oleh server.
3. Jika perlu, menghentikan proses server lama
4. Jika diperlukan, mulai proses server baru

Setelah proses server yang sesuai sudah siap, perintah yang perlu dijalankan dikomunikasikan ke proses tersebut melalui antarmuka gRPC, lalu output Bazel disalurkan kembali ke terminal. Hanya satu perintah yang dapat dijalankan secara bersamaan. Hal ini diimplementasikan menggunakan mekanisme penguncian yang rumit dengan bagian-bagian di C++ dan bagian-bagian di Java. Ada beberapa infrastruktur untuk menjalankan beberapa perintah secara paralel, karena ketidakmampuan untuk menjalankan bazel version secara paralel dengan perintah lain agak memalukan. Pemblokir utama adalah siklus proses BlazeModule dan beberapa status di BlazeRuntime.

Di akhir perintah, server Bazel mengirimkan kode keluar yang harus ditampilkan klien. Hal menarik adalah implementasi bazel run: tugas perintah ini adalah menjalankan sesuatu yang baru saja dibuat Bazel, tetapi tidak dapat melakukannya dari proses server karena tidak memiliki terminal. Jadi, perintah ini akan memberi tahu klien tentang biner apa yang harus ujexec() dan dengan argumen apa.

Jika seseorang menekan Ctrl-C, klien akan menerjemahkannya menjadi panggilan Cancel pada koneksi gRPC, yang akan mencoba menghentikan perintah sesegera mungkin. Setelah Ctrl-C ketiga, klien akan mengirim SIGKILL ke server.

Kode sumber klien berada di src/main/cpp dan protokol yang digunakan untuk berkomunikasi dengan server berada di src/main/protobuf/command_server.proto.

Titik entri utama server adalah BlazeRuntime.main() dan panggilan gRPC dari klien ditangani oleh GrpcServerImpl.run().

Tata letak direktori

Bazel membuat kumpulan direktori yang agak rumit selama build. Deskripsi lengkap tersedia di Tata letak direktori output.

"Repositori utama" adalah hierarki sumber tempat Bazel dijalankan. Hal ini biasanya berkaitan dengan sesuatu yang Anda periksa dari kontrol sumber. Root direktori ini dikenal sebagai "root ruang kerja".

Bazel menempatkan semua datanya di "root pengguna output". Nilai ini biasanya $HOME/.cache/bazel/_bazel_${USER}, tetapi dapat diganti menggunakan opsi startup --output_user_root.

"Basis penginstalan" adalah tempat Bazel diekstrak. Hal ini dilakukan secara otomatis dan setiap versi Bazel mendapatkan subdirektori berdasarkan checksum-nya berdasarkan basis penginstalan. Secara default, nilainya adalah $OUTPUT_USER_ROOT/install dan dapat diubah menggunakan opsi command line --install_base.

"Output base" adalah tempat instance Bazel yang dilampirkan ke ruang kerja tertentu menulis. Setiap basis output memiliki maksimal satu instance server Bazel yang berjalan kapan saja. Biasanya di $OUTPUT_USER_ROOT/<checksum of the path to the workspace>. Hal ini dapat diubah menggunakan opsi startup --output_base, yang, antara lain, berguna untuk mengatasi batasan bahwa hanya satu instance Bazel yang dapat berjalan di ruang kerja mana pun pada waktu tertentu.

Direktori output berisi, antara lain:

• Repositori eksternal yang diambil di $OUTPUT_BASE/external.
• Root exec, direktori yang berisi symlink ke semua kode sumber untuk build saat ini. Berlokasi di $OUTPUT_BASE/execroot. Selama build, direktori kerja adalah $EXECROOT/<name of main repository>. Kami berencana mengubahnya menjadi $EXECROOT, meskipun ini adalah rencana jangka panjang karena merupakan perubahan yang sangat tidak kompatibel.
• File yang di-build selama build.

Proses menjalankan perintah

Setelah server Bazel mendapatkan kontrol dan diberi tahu tentang perintah yang perlu dijalankan, urutan peristiwa berikut akan terjadi:

1. BlazeCommandDispatcher diberi tahu tentang permintaan baru. Fungsi ini menentukan apakah perintah memerlukan ruang kerja untuk dijalankan (hampir setiap perintah kecuali perintah yang tidak ada hubungannya dengan kode sumber, seperti versi atau bantuan) dan apakah perintah lain sedang berjalan.

2. Perintah yang tepat ditemukan. Setiap perintah harus mengimplementasikan antarmuka BlazeCommand dan harus memiliki anotasi @Command (ini sedikit antipola. Sebaiknya jika semua metadata yang diperlukan perintah dijelaskan oleh metode di BlazeCommand)

3. Opsi command line diuraikan. Setiap perintah memiliki opsi command line berbeda yang dijelaskan dalam anotasi @Command.

4. Bus peristiwa dibuat. Bus peristiwa adalah aliran data untuk peristiwa yang terjadi selama build. Beberapa di antaranya diekspor ke luar Bazel di bawah naungan Build Event Protocol untuk memberi tahu dunia tentang proses build yang sedang berlangsung.

5. Perintah mendapatkan kontrol. Perintah yang paling menarik adalah perintah yang menjalankan build: build, pengujian, run, cakupan, dan sebagainya: fungsi ini diimplementasikan oleh BuildTool.

6. Kumpulan pola target di command line diuraikan dan karakter pengganti seperti //pkg:all dan //pkg/... di-resolve. Hal ini diimplementasikan di AnalysisPhaseRunner.evaluateTargetPatterns() dan direalisasikan di Skyframe sebagai TargetPatternPhaseValue.

7. Fase pemuatan/analisis dijalankan untuk menghasilkan grafik tindakan (grafik acyclic terarah dari perintah yang perlu dieksekusi untuk build).

8. Fase eksekusi dijalankan. Artinya, setiap tindakan yang diperlukan untuk mem-build target tingkat teratas yang diminta akan dijalankan.

Opsi command line

Opsi command line untuk pemanggilan Bazel dijelaskan dalam objek OptionsParsingResult, yang pada gilirannya berisi peta dari "class opsi" ke nilai opsi. "Class opsi" adalah subclass dari OptionsBase dan mengelompokkan opsi command line yang terkait satu sama lain. Contoh:

1. Opsi yang terkait dengan bahasa pemrograman (CppOptions atau JavaOptions). Opsi ini harus berupa subclass FragmentOptions dan pada akhirnya digabungkan ke dalam objek BuildOptions.
2. Opsi yang terkait dengan cara Bazel mengeksekusi tindakan (ExecutionOptions)

Opsi ini dirancang untuk digunakan dalam fase analisis dan (baik melalui RuleContext.getFragment() di Java atau ctx.fragments di Starlark). Beberapa di antaranya (misalnya, apakah akan melakukan pemindaian C++ atau tidak) dibaca dalam fase eksekusi, tetapi hal itu selalu memerlukan plumbing eksplisit karena BuildConfiguration tidak tersedia saat itu. Untuk informasi selengkapnya, lihat bagian "Konfigurasi".

PERINGATAN: Kita ingin berpura-pura bahwa instance OptionsBase tidak dapat diubah dan menggunakannya dengan cara itu (seperti bagian dari SkyKeys). Ini tidak benar dan mengubahnya adalah cara yang sangat baik untuk merusak Bazel dengan cara halus yang sulit di-debug. Sayangnya, membuat data tersebut benar-benar tidak dapat diubah adalah upaya yang besar. (Anda dapat mengubah FragmentOptions segera setelah konstruksi sebelum orang lain mendapatkan kesempatan untuk menyimpan referensi ke sana dan sebelum equals() atau hashCode() dipanggil.)

Bazel mempelajari class opsi dengan cara berikut:

1. Beberapa di antaranya terintegrasi dengan Bazel (CommonCommandOptions)
2. Dari anotasi @Command di setiap perintah Bazel
3. Dari ConfiguredRuleClassProvider (ini adalah opsi command line yang terkait dengan setiap bahasa pemrograman)
4. Aturan Starlark juga dapat menentukan opsinya sendiri (lihat di sini)

Setiap opsi (kecuali opsi yang ditentukan Starlark) adalah variabel anggota subclass FragmentOptions yang memiliki anotasi @Option, yang menentukan nama dan jenis opsi command line beserta beberapa teks bantuan.

Jenis Java dari nilai opsi command line biasanya sesuatu yang sederhana (string, bilangan bulat, Boolean, label, dll.). Namun, kita juga mendukung opsi jenis yang lebih rumit; dalam hal ini, tugas mengonversi dari string command line ke jenis data bergantung pada implementasi com.google.devtools.common.options.Converter.

Pohon sumber, seperti yang terlihat oleh Bazel

Bazel bergerak di bidang pembuatan software, yang dilakukan dengan membaca dan menafsirkan kode sumber. Totalitas kode sumber yang digunakan Bazel disebut "ruang kerja" dan disusun ke dalam repositori, paket, dan aturan.

Repositori

"Repositori" adalah hierarki sumber tempat developer bekerja; biasanya mewakili satu project. Nenek moyang Bazel, Blaze, beroperasi di monorepo, yaitu, satu hierarki sumber yang berisi semua kode sumber yang digunakan untuk menjalankan build. Sebaliknya, Bazel mendukung project yang kode sumbernya mencakup beberapa repositori. Repositori tempat Bazel dipanggil disebut "repositori utama", yang lainnya disebut "repositori eksternal".

Repositori ditandai dengan file batas repo (MODULE.bazel, REPO.bazel, atau dalam konteks lama, WORKSPACE atau WORKSPACE.bazel) di direktori root-nya. Repositori utama adalah hierarki sumber tempat Anda memanggil Bazel. Repositori eksternal ditentukan dengan berbagai cara; lihat ringkasan dependensi eksternal untuk informasi selengkapnya.

Kode repositori eksternal di-symlink atau didownload di $OUTPUT_BASE/external.

Saat menjalankan build, seluruh hierarki sumber harus digabungkan; hal ini dilakukan oleh SymlinkForest, yang membuat symlink setiap paket di repositori utama ke $EXECROOT dan setiap repositori eksternal ke $EXECROOT/external atau $EXECROOT/...

Paket

Setiap repositori terdiri dari paket, kumpulan file terkait, dan spesifikasi dependensi. Hal ini ditentukan oleh file yang disebut BUILD atau BUILD.bazel. Jika keduanya ada, Bazel lebih memilih BUILD.bazel; alasan mengapa file BUILD masih diterima adalah karena nenek moyang Bazel, Blaze, menggunakan nama file ini. Namun, ternyata ini adalah segmen jalur yang umum digunakan, terutama di Windows, tempat nama file tidak peka huruf besar/kecil.

Paket tidak saling bergantung: perubahan pada file BUILD paket tidak dapat menyebabkan paket lain berubah. Penambahan atau penghapusan file BUILD _dapat _mengubah paket lain, karena glob rekursif berhenti di batas paket sehingga kehadiran file BUILD menghentikan rekursi.

Evaluasi file BUILD disebut "pemuatan paket". Class ini diimplementasikan di class PackageFactory, berfungsi dengan memanggil penafsir Starlark dan memerlukan pengetahuan tentang kumpulan class aturan yang tersedia. Hasil pemuatan paket adalah objek Package. Sebagian besar adalah peta dari string (nama target) ke target itu sendiri.

Sebagian besar kompleksitas selama pemuatan paket adalah globbing: Bazel tidak mengharuskan setiap file sumber dicantumkan secara eksplisit dan sebagai gantinya dapat menjalankan glob (seperti glob(["**/*.java"])). Tidak seperti shell, shell mendukung glob rekursif yang turun ke subdirektori (tetapi tidak menjadi sub-paket). Hal ini memerlukan akses ke sistem file dan karena proses tersebut bisa jadi lambat, kami menerapkan segala jenis trik untuk menjalankannya secara paralel dan seefisien mungkin.

Globbing diimplementasikan di class berikut:

• LegacyGlobber, globber yang cepat dan tidak mengetahui Skyframe
• SkyframeHybridGlobber, versi yang menggunakan Skyframe dan kembali ke globber lama untuk menghindari "Skyframe dimulai ulang" (dijelaskan di bawah)

Class Package itu sendiri berisi beberapa anggota yang secara eksklusif digunakan untuk menguraikan paket "eksternal" (terkait dependensi eksternal) dan yang tidak membuat paket nyata. Hal ini merupakan kekurangan desain karena objek yang mendeskripsikan paket reguler tidak boleh berisi kolom yang mendeskripsikan hal lain. Ini mencakup:

• Pemetaan repositori
• Toolchain terdaftar
• Platform eksekusi yang terdaftar

Idealnya, akan ada lebih banyak pemisahan antara mengurai paket "eksternal" dari mengurai paket reguler sehingga Package tidak perlu memenuhi kebutuhan keduanya. Sayangnya, hal ini sulit dilakukan karena keduanya terjalin cukup erat.

Label, Target, dan Aturan

Paket terdiri dari target yang memiliki jenis berikut:

1. File: hal yang merupakan input atau output build. Dalam bahasa Bazel, kami menyebutnya artefak (dibahas di tempat lain). Tidak semua file yang dibuat selama build adalah target; output Bazel biasanya tidak memiliki label yang terkait.
2. Aturan: ini menjelaskan langkah-langkah untuk mendapatkan output dari input-nya. Jenis ini umumnya dikaitkan dengan bahasa pemrograman (seperti cc_library, java_library, atau py_library), tetapi ada beberapa jenis yang tidak bergantung pada bahasa (seperti genrule atau filegroup)
3. Grup paket: dibahas di bagian Visibilitas.

Nama target disebut Label. Sintaksis label adalah @repo//pac/kage:name, dengan repo adalah nama repositori tempat Label berada, pac/kage adalah direktori tempat file BUILD-nya berada, dan name adalah jalur file (jika label merujuk ke file sumber) yang terkait dengan direktori paket. Saat merujuk ke target di command line, beberapa bagian label dapat dihilangkan:

1. Jika repositori dihilangkan, label akan dianggap berada di repositori utama.
2. Jika bagian paket dihilangkan (seperti name atau :name), label akan diambil untuk berada dalam paket direktori kerja saat ini (jalur relatif yang berisi referensi uplevel (..) tidak diizinkan)

Jenis aturan (seperti "library C++") disebut "class aturan". Class aturan dapat diimplementasikan di Starlark (fungsi rule()) atau di Java (disebut "aturan native", ketik RuleClass). Dalam jangka panjang, setiap aturan khusus bahasa akan diimplementasikan di Starlark, tetapi beberapa keluarga aturan lama (seperti Java atau C++) masih ada di Java untuk saat ini.

Class aturan Starlark perlu diimpor di awal file BUILD menggunakan pernyataan load(), sedangkan class aturan Java "secara bawaan" diketahui oleh Bazel, karena telah didaftarkan dengan ConfiguredRuleClassProvider.

Class aturan berisi informasi seperti:

1. Atributnya (seperti srcs, deps): jenis, nilai default, batasan, dll.
2. Transisi dan aspek konfigurasi yang dilampirkan ke setiap atribut, jika ada
3. Penerapan aturan
4. Penyedia info transitif yang "biasanya" dibuat oleh aturan

Catatan terminologi: Dalam codebase, kita sering menggunakan "Aturan" untuk menunjukkan target yang dibuat oleh class aturan. Namun, dalam Starlark dan dalam dokumentasi yang ditampilkan kepada pengguna, "Rule" harus digunakan secara eksklusif untuk merujuk ke class aturan itu sendiri; targetnya hanyalah "target". Perhatikan juga bahwa meskipun RuleClass memiliki "class" dalam namanya, tidak ada hubungan pewarisan Java antara class aturan dan target dari jenis tersebut.

Skyframe

Framework evaluasi yang mendasari Bazel disebut Skyframe. Modelnya adalah semua yang perlu dibuat selama build diatur ke dalam grafik acyclic terarah dengan tepi yang mengarah dari setiap bagian data ke dependensinya, yaitu, bagian data lain yang perlu diketahui untuk membuatnya.

Node dalam grafik disebut SkyValue dan namanya disebut SkyKey. Keduanya tidak dapat diubah; hanya objek yang tidak dapat diubah yang dapat dijangkau dari keduanya. Invarian ini hampir selalu berlaku, dan jika tidak berlaku (seperti untuk setiap class opsi BuildOptions, yang merupakan anggota BuildConfigurationValue dan SkyKey-nya), kami berusaha keras untuk tidak mengubahnya atau mengubahnya hanya dengan cara yang tidak dapat diamati dari luar. Dari hal ini, dapat disimpulkan bahwa semua yang dikomputasi dalam Skyframe (seperti target yang dikonfigurasi) juga harus tidak dapat diubah.

Cara paling mudah untuk mengamati grafik Skyframe adalah dengan menjalankan bazel dump --skyframe=deps, yang membuang grafik, satu SkyValue per baris. Sebaiknya lakukan untuk build kecil, karena ukurannya bisa cukup besar.

Skyframe tersedia dalam paket com.google.devtools.build.skyframe. Paket com.google.devtools.build.lib.skyframe yang bernama sama berisi implementasi Bazel di atas Skyframe. Informasi selengkapnya tentang Skyframe tersedia di sini.

Untuk mengevaluasi SkyKey tertentu menjadi SkyValue, Skyframe akan memanggil SkyFunction yang sesuai dengan jenis kunci. Selama evaluasi, fungsi dapat meminta dependensi lain dari Skyframe dengan memanggil berbagai overload SkyFunction.Environment.getValue(). Hal ini memiliki efek samping berupa pendaftaran dependensi tersebut ke dalam grafik internal Skyframe, sehingga Skyframe akan mengetahui untuk mengevaluasi ulang fungsi saat salah satu dependensinya berubah. Dengan kata lain, caching dan komputasi inkremental Skyframe berfungsi pada tingkat perincian SkyFunction dan SkyValue.

Setiap kali SkyFunction meminta dependensi yang tidak tersedia, getValue() akan menampilkan null. Fungsi ini kemudian akan memberikan kontrol kembali ke Skyframe dengan menampilkan null. Pada waktu mendatang, Skyframe akan mengevaluasi dependensi yang tidak tersedia, lalu memulai ulang fungsi tersebut dari awal — hanya kali ini panggilan getValue() akan berhasil dengan hasil non-null.

Konsekuensinya adalah setiap komputasi yang dilakukan di dalam SkyFunction sebelum dimulai ulang harus diulang. Namun, ini tidak termasuk pekerjaan yang dilakukan untuk mengevaluasi dependensi SkyValues, yang di-cache. Oleh karena itu, kami biasanya mengatasi masalah ini dengan:

1. Mendeklarasikan dependensi dalam beberapa batch (dengan menggunakan getValuesAndExceptions()) untuk membatasi jumlah mulai ulang.
2. Memecah SkyValue menjadi bagian-bagian terpisah yang dikomputasi oleh berbagai SkyFunction, sehingga dapat dikomputasi dan di-cache secara independen. Hal ini harus dilakukan secara strategis, karena berpotensi meningkatkan penggunaan memori.
3. Menyimpan status di antara mulai ulang, baik menggunakan SkyFunction.Environment.getState(), atau menyimpan cache statis ad hoc "di belakang Skyframe".

Pada dasarnya, kita memerlukan jenis solusi ini karena kita secara rutin memiliki ratusan ribu node Skyframe dalam penerbangan, dan Java tidak mendukung thread ringan.

Starlark

Starlark adalah bahasa khusus domain yang digunakan orang untuk mengonfigurasi dan memperluas Bazel. Python ini dianggap sebagai subset Python terbatas yang memiliki lebih sedikit jenis, lebih banyak batasan pada alur kontrol, dan yang paling penting, jaminan immutability yang kuat untuk memungkinkan pembacaan serentak. Ini bukanlah pengujian yang telah selesai, sehingga beberapa (tetapi tidak semua) pengguna enggan menyelesaikan tugas pemrograman umum dalam bahasa tersebut.

Starlark diimplementasikan dalam paket net.starlark.java. Library ini juga memiliki implementasi Go independen di sini. Implementasi Java yang digunakan di Bazel saat ini adalah penafsir.

Starlark digunakan dalam beberapa konteks, termasuk:

1. File BUILD. Di sinilah target build baru ditentukan. Kode Starlark yang berjalan dalam konteks ini hanya memiliki akses ke konten file BUILD itu sendiri dan file .bzl yang dimuat olehnya.
2. File MODULE.bazel. Di sinilah dependensi eksternal ditentukan. Kode Starlark yang berjalan dalam konteks ini hanya memiliki akses yang sangat terbatas ke beberapa perintah yang telah ditentukan sebelumnya.
3. File .bzl. Di sinilah aturan build baru, aturan repo, ekstensi modul ditentukan. Kode Starlark di sini dapat menentukan fungsi baru dan memuat dari file .bzl lainnya.

Dialek yang tersedia untuk file BUILD dan .bzl sedikit berbeda karena mengekspresikan hal yang berbeda. Daftar perbedaannya tersedia di sini.

Informasi selengkapnya tentang Starlark tersedia di sini.

Fase pemuatan/analisis

Fase pemuatan/analisis adalah saat Bazel menentukan tindakan yang diperlukan untuk membuat aturan tertentu. Unit dasarnya adalah "target yang dikonfigurasi", yang merupakan pasangan (target, konfigurasi) yang cukup masuk akal.

Ini disebut "fase pemuatan/analisis" karena dapat dibagi menjadi dua bagian yang berbeda, yang sebelumnya diserialisasi, tetapi sekarang dapat tumpang-tindih dalam waktu:

1. Memuat paket, yaitu mengubah file BUILD menjadi objek Package yang mewakilinya
2. Menganalisis target yang dikonfigurasi, yaitu menjalankan implementasi aturan untuk menghasilkan grafik tindakan

Setiap target yang dikonfigurasi dalam penutupan transitif target yang dikonfigurasi yang diminta di command line harus dianalisis dari bawah ke atas; yaitu, node daun terlebih dahulu, lalu hingga node di command line. Input untuk analisis satu target yang dikonfigurasi adalah:

1. Konfigurasi. ("cara" membuat aturan tersebut; misalnya, platform target, tetapi juga hal-hal seperti opsi command line yang ingin diteruskan pengguna ke compiler C++)
2. Dependensi langsung. Penyedia info transitifnya tersedia untuk aturan yang sedang dianalisis. Fungsi ini disebut demikian karena menyediakan "gabungan" informasi dalam penutupan transitif target yang dikonfigurasi, seperti semua file .jar di classpath atau semua file .o yang perlu ditautkan ke biner C++)
3. Targetnya sendiri. Ini adalah hasil pemuatan paket tempat target berada. Untuk aturan, hal ini mencakup atributnya, yang biasanya merupakan hal yang penting.
4. Implementasi target yang dikonfigurasi. Untuk aturan, ini dapat berada di Starlark atau di Java. Semua target yang dikonfigurasi non-aturan diterapkan di Java.

Output dari menganalisis target yang dikonfigurasi adalah:

1. Penyedia info transitif yang mengonfigurasi target yang bergantung padanya dapat mengakses
2. Artefak yang dapat dibuatnya dan tindakan yang menghasilkannya.

API yang ditawarkan ke aturan Java adalah RuleContext, yang setara dengan argumen ctx dari aturan Starlark. API-nya lebih canggih, tetapi pada saat yang sama, lebih mudah untuk melakukan Hal Buruk™, misalnya menulis kode yang kompleksitas waktu atau ruangnya kuadrat (atau lebih buruk), membuat server Bazel error dengan pengecualian Java, atau melanggar invarian (seperti dengan tidak sengaja mengubah instance Options atau dengan membuat target yang dikonfigurasi dapat diubah)

Algoritme yang menentukan dependensi langsung target yang dikonfigurasi berada di DependencyResolver.dependentNodeMap().

Konfigurasi

Konfigurasi adalah "cara" membuat target: untuk platform apa, dengan opsi command line apa, dll.

Target yang sama dapat dibuat untuk beberapa konfigurasi dalam build yang sama. Hal ini berguna, misalnya, saat kode yang sama digunakan untuk alat yang dijalankan selama build dan untuk kode target dan kita melakukan cross-kompilasi atau saat kita mem-build aplikasi Android fat (yang berisi kode native untuk beberapa arsitektur CPU)

Secara konsep, konfigurasi adalah instance BuildOptions. Namun, dalam prakteknya, BuildOptions digabungkan oleh BuildConfiguration yang menyediakan berbagai fungsi tambahan. Perubahan ini diperluas dari bagian atas grafik dependensi ke bagian bawah. Jika berubah, build perlu dianalisis ulang.

Hal ini menyebabkan anomali seperti harus menganalisis ulang seluruh build jika, misalnya, jumlah pengujian yang diminta berubah, meskipun itu hanya memengaruhi target pengujian (kami berencana untuk "memangkas" konfigurasi agar ini tidak terjadi, tetapi belum siap).

Jika implementasi aturan memerlukan bagian dari konfigurasi, implementasi tersebut harus mendeklarasikannya dalam definisinya menggunakan RuleClass.Builder.requiresConfigurationFragments(). Hal ini dilakukan untuk menghindari kesalahan (seperti aturan Python yang menggunakan fragmen Java) dan untuk memfasilitasi pemangkasan konfigurasi sehingga jika opsi Python berubah, target C++ tidak perlu dianalisis ulang.

Konfigurasi aturan tidak harus sama dengan konfigurasi aturan "induk"-nya. Proses mengubah konfigurasi di tepi dependensi disebut "transisi konfigurasi". Hal ini dapat terjadi di dua tempat:

1. Di tepi dependensi. Transisi ini ditentukan dalam Attribute.Builder.cfg() dan merupakan fungsi dari Rule (tempat transisi terjadi) dan BuildOptions (konfigurasi asli) ke satu atau beberapa BuildOptions (konfigurasi output).
2. Pada setiap edge masuk ke target yang dikonfigurasi. Ini ditentukan dalam RuleClass.Builder.cfg().

Class yang relevan adalah TransitionFactory dan ConfigurationTransition.

Transisi konfigurasi digunakan, misalnya:

1. Untuk mendeklarasikan bahwa dependensi tertentu digunakan selama build dan harus di-build dalam arsitektur eksekusi
2. Untuk mendeklarasikan bahwa dependensi tertentu harus dibuat untuk beberapa arsitektur (misalnya untuk kode native dalam APK Android berukuran besar)

Jika transisi konfigurasi menghasilkan beberapa konfigurasi, transisi tersebut disebut transisi terpisah.

Transisi konfigurasi juga dapat diterapkan di Starlark (dokumentasi di sini)

Penyedia info transitif

Penyedia info transitif adalah cara (dan _satu-satunya _cara) bagi target yang dikonfigurasi untuk memberi tahu hal-hal tentang target lain yang dikonfigurasi yang bergantung padanya. Nama "transitif" digunakan pada namanya adalah karena ini biasanya merupakan semacam gabungan dari penutupan transitif dari target yang dikonfigurasi.

Umumnya ada korespondensi 1:1 antara penyedia info transitif Java dan Starlark (pengecualian adalah DefaultInfo yang merupakan penggabungan FileProvider, FilesToRunProvider, dan RunfilesProvider karena API tersebut dianggap lebih mirip Starlark daripada transliterasi langsung dari Java). Kuncinya adalah salah satu hal berikut:

1. Objek Class Java. Ini hanya tersedia untuk penyedia yang tidak dapat diakses dari Starlark. Penyedia ini adalah subclass dari TransitiveInfoProvider.
2. String. Hal ini merupakan warisan dan sangat tidak disarankan karena rentan terhadap pertentangan nama. Penyedia info transitif tersebut adalah subclass langsung dari build.lib.packages.Info .
3. Simbol penyedia. Ini dapat dibuat dari Starlark menggunakan fungsi provider() dan merupakan cara yang direkomendasikan untuk membuat penyedia baru. Simbol tersebut diwakili oleh instance Provider.Key di Java.

Penyedia baru yang diimplementasikan di Java harus diimplementasikan menggunakan BuiltinProvider. NativeProvider tidak digunakan lagi (kami belum sempat menghapusnya) dan subclass TransitiveInfoProvider tidak dapat diakses dari Starlark.

Target yang dikonfigurasi

Target yang dikonfigurasi diterapkan sebagai RuleConfiguredTargetFactory. Ada subclass untuk setiap class aturan yang diimplementasikan di Java. Target yang dikonfigurasi Starlark dibuat melalui StarlarkRuleConfiguredTargetUtil.buildRule() .

Factory target yang dikonfigurasi harus menggunakan RuleConfiguredTargetBuilder untuk membuat nilai yang ditampilkan. Isinya terdiri dari hal-hal berikut:

1. filesToBuild-nya, konsep samar "kumpulan file yang mewakili aturan ini". Ini adalah file yang dibuat saat target yang dikonfigurasi ada di command line atau di src genrule.
2. Runfile, reguler, dan data.
3. Grup outputnya. Ini adalah berbagai "kumpulan file lain" yang dapat di-build oleh aturan. Atribut ini dapat diakses menggunakan atribut output_group dari aturan filegroup di BUILD dan menggunakan penyedia OutputGroupInfo di Java.

Runfile

Beberapa biner memerlukan file data untuk dijalankan. Contohnya adalah pengujian yang memerlukan file input. Hal ini direpresentasikan dalam Bazel oleh konsep "runfiles". "Runfiles tree" adalah hierarki direktori file data untuk biner tertentu. Library ini dibuat di sistem file sebagai hierarki symlink dengan masing-masing symlink yang mengarah ke file dalam sumber hierarki output.

Kumpulan runfile direpresentasikan sebagai instance Runfiles. Secara konseptual, ini adalah peta dari jalur file dalam hierarki runfile ke instance Artifact yang mewakilinya. Hal ini sedikit lebih rumit daripada satu Map karena dua alasan:

• Sering kali, jalur runfile file sama dengan execpath-nya. Kita menggunakannya untuk menghemat RAM.
• Ada berbagai jenis entri lama dalam hierarki runfile, yang juga perlu direpresentasikan.

Runfile dikumpulkan menggunakan RunfilesProvider: instance class ini mewakili runfile target yang dikonfigurasi (seperti library) dan kebutuhan penutupan transitipnya, dan dikumpulkan seperti kumpulan bertingkat (sebenarnya, diimplementasikan menggunakan kumpulan bertingkat di balik layar): setiap target menggabungkan runfile dependensinya, menambahkan beberapa runfile-nya sendiri, lalu mengirim kumpulan yang dihasilkan ke atas dalam grafik dependensi. Instance RunfilesProvider berisi dua instance Runfiles, satu untuk saat aturan bergantung pada atribut "data" dan satu untuk setiap jenis dependensi masuk lainnya. Hal ini karena target terkadang menampilkan runfile yang berbeda jika bergantung pada atribut data daripada yang lain. Ini adalah perilaku lama yang tidak diinginkan dan belum kami hapus.

Runfile biner direpresentasikan sebagai instance RunfilesSupport. Hal ini berbeda dengan Runfiles karena RunfilesSupport memiliki kemampuan untuk benar-benar dibuat (tidak seperti Runfiles, yang hanya merupakan pemetaan). Tindakan ini memerlukan komponen tambahan berikut:

• Manifes runfile input. Ini adalah deskripsi serial dari hierarki runfile. File ini digunakan sebagai proxy untuk konten hierarki runfile dan Bazel mengasumsikan bahwa hierarki runfile berubah jika dan hanya jika konten manifes berubah.
• Manifes runfile output. Library ini digunakan oleh library runtime yang menangani hierarki runfile, terutama di Windows, yang terkadang tidak mendukung link simbolis.
• Perantara runfiles. Agar hierarki runfile ada, Anda harus mem-build hierarki symlink dan artefak yang dituju oleh symlink. Untuk mengurangi jumlah tepi dependensi, middleman runfile dapat digunakan untuk merepresentasikan semua ini.
• Argumen command line untuk menjalankan biner yang file run-nya mewakili objek RunfilesSupport.

Aspek

Aspek adalah cara untuk "menyebarkan komputasi ke bawah grafik dependensi". Hal ini dijelaskan untuk pengguna Bazel di sini. Contoh motivasi yang baik adalah buffering protokol: aturan proto_library tidak boleh mengetahui bahasa tertentu, tetapi membuat implementasi pesan buffering protokol ("unit dasar" buffering protokol) dalam bahasa pemrograman apa pun harus digabungkan dengan aturan proto_library sehingga jika dua target dalam bahasa yang sama bergantung pada buffering protokol yang sama, buffering tersebut hanya akan dibuat sekali.

Sama seperti target yang dikonfigurasi, target ini direpresentasikan di Skyframe sebagai SkyValue dan cara pembuatannya sangat mirip dengan cara pembuatan target yang dikonfigurasi: target ini memiliki class factory yang disebut ConfiguredAspectFactory yang memiliki akses ke RuleContext, tetapi tidak seperti factory target yang dikonfigurasi, target ini juga mengetahui target yang dikonfigurasi yang dilampirkan dan penyedianya.

Kumpulan aspek yang disebarkan ke bawah grafik dependensi ditentukan untuk setiap atribut menggunakan fungsi Attribute.Builder.aspects(). Ada beberapa class dengan nama yang membingungkan yang berpartisipasi dalam proses ini:

1. AspectClass adalah implementasi aspek. Token dapat berupa di Java (dalam hal ini subclass) atau di Starlark (dalam hal ini adalah instance dari StarlarkAspectClass). Sama halnya dengan RuleConfiguredTargetFactory.
2. AspectDefinition adalah definisi aspek; mencakup penyedia yang diperlukan, penyedia yang disediakan, dan berisi referensi ke implementasinya, seperti instance AspectClass yang sesuai. Ini analog dengan RuleClass.
3. AspectParameters adalah cara untuk memparametrisasi aspek yang disebarkan ke bawah grafik dependensi. Saat ini, ini adalah peta string ke string. Contoh yang baik tentang kegunaannya adalah buffering protokol: jika suatu bahasa memiliki beberapa API, informasi tentang API mana yang harus dibuat buffering protokolnya harus disebarkan ke bawah grafik dependensi.
4. Aspect mewakili semua data yang diperlukan untuk menghitung aspek yang menyebar ke bawah grafik dependensi. Class ini terdiri dari class aspek, definisi, dan parameternya.
5. RuleAspect adalah fungsi yang menentukan aspek mana yang harus di-propagasi oleh aturan tertentu. Ini adalah fungsi Rule -> Aspect.

Detail yang tidak terduga adalah bahwa aspek dapat dilampirkan ke aspek lain; misalnya, aspek yang mengumpulkan classpath untuk Java IDE mungkin ingin mengetahui tentang semua file .jar di classpath, tetapi beberapa di antaranya adalah buffering protokol. Dalam hal ini, aspek IDE perlu ditambahkan ke pasangan (aturan proto_library + aspek proto Java).

Kompleksitas aspek pada aspek ditangkap dalam class AspectCollection.

Platform dan toolchain

Bazel mendukung build multi-platform, yaitu build yang mungkin memiliki beberapa arsitektur tempat tindakan build berjalan dan beberapa arsitektur untuk kode yang di-build. Arsitektur ini disebut sebagai platform dalam istilah Bazel (dokumentasi lengkap di sini)

Platform dijelaskan oleh pemetaan nilai kunci dari setelan batasan (seperti konsep "arsitektur CPU") ke nilai batasan (seperti CPU tertentu seperti x86_64). Kita memiliki "kamus" setelan dan nilai batasan yang paling umum digunakan di repositori @platforms.

Konsep toolchain berasal dari fakta bahwa bergantung pada platform tempat build berjalan dan platform yang ditargetkan, Anda mungkin perlu menggunakan compiler yang berbeda; misalnya, toolchain C++ tertentu dapat berjalan di OS tertentu dan dapat menargetkan beberapa OS lainnya. Bazel harus menentukan compiler C++ yang digunakan berdasarkan eksekusi set dan platform target (dokumentasi untuk toolchain di sini).

Untuk melakukannya, toolchain dianotasikan dengan kumpulan batasan platform eksekusi dan target yang didukungnya. Untuk melakukannya, definisi toolchain dibagi menjadi dua bagian:

1. Aturan toolchain() yang menjelaskan kumpulan batasan eksekusi dan target yang didukung toolchain dan memberi tahu jenis toolchain (seperti C++ atau Java) (yang terakhir diwakili oleh aturan toolchain_type())
2. Aturan khusus bahasa yang menjelaskan toolchain sebenarnya (seperti cc_toolchain())

Hal ini dilakukan dengan cara ini karena kita perlu mengetahui batasan untuk setiap toolchain guna melakukan resolusi toolchain dan aturan *_toolchain() khusus bahasa berisi lebih banyak informasi daripada itu, sehingga memerlukan lebih banyak waktu untuk dimuat.

Platform eksekusi ditentukan dengan salah satu cara berikut:

1. Dalam file MODULE.bazel menggunakan fungsi register_execution_platforms()
2. Di command line menggunakan opsi command line --extra_execution_platforms

Kumpulan platform eksekusi yang tersedia dikomputasi di RegisteredExecutionPlatformsFunction .

Platform target untuk target yang dikonfigurasi ditentukan oleh PlatformOptions.computeTargetPlatform() . Ini adalah daftar platform karena pada akhirnya kami ingin mendukung beberapa platform target, tetapi belum diterapkan secara penuh.

Kumpulan toolchain yang akan digunakan untuk target yang dikonfigurasi ditentukan oleh ToolchainResolutionFunction. Ini adalah fungsi dari:

• Kumpulan toolchain terdaftar (dalam file MODULE.bazel dan konfigurasi)
• Platform target dan eksekusi yang diinginkan (dalam konfigurasi)
• Kumpulan jenis toolchain yang diperlukan oleh target yang dikonfigurasi (di UnloadedToolchainContextKey)
• Kumpulan batasan platform eksekusi target yang dikonfigurasi (atribut exec_compatible_with) dan konfigurasi (--experimental_add_exec_constraints_to_targets), di UnloadedToolchainContextKey

Hasilnya adalah UnloadedToolchainContext, yang pada dasarnya adalah peta dari jenis toolchain (diwakili sebagai instance ToolchainTypeInfo) ke label toolchain yang dipilih. Ini disebut "di-unload" karena tidak berisi toolchain itu sendiri, hanya labelnya.

Kemudian, toolchain benar-benar dimuat menggunakan ResolvedToolchainContext.load() dan digunakan oleh implementasi target yang dikonfigurasi yang memintanya.

Kami juga memiliki sistem lama yang mengandalkan adanya satu konfigurasi "host" dan konfigurasi target yang direpresentasikan oleh berbagai flag konfigurasi, seperti --cpu . Kami secara bertahap bertransisi ke sistem di atas. Untuk menangani kasus saat pengguna mengandalkan nilai konfigurasi lama, kami telah menerapkan pemetaan platform untuk menerjemahkan antara flag lama dan batasan platform gaya baru. Kodenya berada di PlatformMappingFunction dan menggunakan "bahasa kecil" non-Starlark.

Batasan

Terkadang, seseorang ingin menetapkan target sebagai hanya kompatibel dengan beberapa platform. Sayangnya, Bazel memiliki beberapa mekanisme untuk mencapai tujuan ini:

• Batasan khusus aturan
• environment_group()/environment()
• Batasan platform

Batasan khusus aturan sebagian besar digunakan dalam Google untuk aturan Java; batasan ini akan dihapus dan tidak tersedia di Bazel, tetapi kode sumber mungkin berisi referensi ke batasan tersebut. Atribut yang mengatur hal ini disebut constraints= .

environment_group() dan environment()

Aturan ini adalah mekanisme lama dan tidak digunakan secara luas.

Semua aturan build dapat mendeklarasikan "lingkungan" tempat aturan tersebut dapat dibuat, dengan "lingkungan" adalah instance aturan environment().

Ada berbagai cara untuk menentukan lingkungan yang didukung untuk aturan:

1. Melalui atribut restricted_to=. Ini adalah bentuk spesifikasi paling langsung; cara ini mendeklarasikan kumpulan lingkungan yang tepat yang didukung aturan untuk grup ini.
2. Melalui atribut compatible_with=. Ini mendeklarasikan lingkungan yang didukung aturan selain lingkungan "standar" yang didukung secara default.
3. Melalui atribut tingkat paket default_restricted_to= dan default_compatible_with=.
4. Melalui spesifikasi default dalam aturan environment_group(). Setiap lingkungan termasuk dalam grup rekan yang terkait secara tematik (seperti "arsitektur CPU", "versi JDK", atau "sistem operasi seluler"). Definisi grup lingkungan mencakup lingkungan mana dari lingkungan ini yang harus didukung oleh "default" jika tidak ditentukan oleh atribut restricted_to= / environment(). Aturan tanpa atribut tersebut akan mewarisi semua default.
5. Melalui class aturan default. Tindakan ini akan mengganti default global untuk semua instance class aturan yang diberikan. Hal ini dapat digunakan, misalnya, untuk membuat semua aturan *_test dapat diuji tanpa setiap instance harus secara eksplisit mendeklarasikan kemampuan ini.

environment() diterapkan sebagai aturan reguler, sedangkan environment_group() adalah subclass dari Target, tetapi bukan Rule (EnvironmentGroup) dan fungsi yang tersedia secara default dari Starlark (StarlarkLibrary.environmentGroup()) yang pada akhirnya membuat target dengan nama yang sama. Hal ini untuk menghindari dependensi siklus yang akan muncul karena setiap lingkungan perlu mendeklarasikan grup lingkungan tempatnya berada dan setiap grup lingkungan perlu mendeklarasikan lingkungan defaultnya.

Build dapat dibatasi untuk lingkungan tertentu dengan opsi command line --target_environment.

Implementasi pemeriksaan batasan ada di RuleContextConstraintSemantics dan TopLevelConstraintSemantics.

Batasan platform

Cara "resmi" saat ini untuk menjelaskan platform yang kompatibel dengan target adalah dengan menggunakan batasan yang sama yang digunakan untuk mendeskripsikan toolchain dan platform. Perubahan ini sedang ditinjau dalam permintaan pull #10945.

Visibilitas

Jika Anda mengerjakan codebase besar dengan banyak developer (seperti di Google), Anda harus berhati-hati untuk mencegah orang lain bergantung secara sewenang-wenang pada kode Anda. Jika tidak, sesuai dengan hukum Hyrum, orang akan bergantung pada perilaku yang Anda anggap sebagai detail penerapan.

Bazel mendukung hal ini dengan mekanisme yang disebut visibilitas: Anda dapat mendeklarasikan bahwa target tertentu hanya dapat diandalkan menggunakan atribut visibilitas. Atribut ini sedikit khusus karena, meskipun menyimpan daftar label, label ini dapat mengenkode pola melalui nama paket, bukan pointer ke target tertentu. (Ya, ini adalah cacat desain.)

Hal ini diterapkan di tempat berikut:

• Antarmuka RuleVisibility mewakili deklarasi visibilitas. Nilai ini dapat berupa konstanta (sepenuhnya publik atau sepenuhnya pribadi) atau daftar label.
• Label dapat merujuk ke grup paket (daftar paket standar), ke paket secara langsung (//pkg:__pkg__) atau sub-pohon paket (//pkg:__subpackages__). Hal ini berbeda dengan sintaksis command line, yang menggunakan //pkg:* atau //pkg/....
• Grup paket diimplementasikan sebagai targetnya sendiri (PackageGroup) dan target yang dikonfigurasi (PackageGroupConfiguredTarget). Kita mungkin dapat mengganti ini dengan aturan sederhana jika ingin. Logikanya diterapkan dengan bantuan: PackageSpecification, yang sesuai dengan satu pola seperti //pkg/...; PackageGroupContents, yang sesuai dengan satu atribut packages package_group; dan PackageSpecificationProvider, yang menggabungkan package_group dan includes transitifnya.
• Konversi dari daftar label visibilitas ke dependensi dilakukan di DependencyResolver.visitTargetVisibility dan beberapa tempat lainnya.
• Pemeriksaan sebenarnya dilakukan di CommonPrerequisiteValidator.validateDirectPrerequisiteVisibility()

Kumpulan bertingkat

Sering kali, target yang dikonfigurasi menggabungkan kumpulan file dari dependensinya, menambahkan filenya sendiri, dan menggabungkan kumpulan agregat ke dalam penyedia info transitif sehingga target yang dikonfigurasi yang bergantung padanya dapat melakukan hal yang sama. Contoh:

• File header C++ yang digunakan untuk build
• File objek yang mewakili penutupan transitif cc_library
• Kumpulan file .jar yang harus berada di classpath agar aturan Java dapat dikompilasi atau dijalankan
• Kumpulan file Python dalam penutupan transitif aturan Python

Jika kita melakukannya dengan cara naif menggunakan, misalnya, List atau Set, kita akan mendapatkan penggunaan memori kuadrat: jika ada rantai aturan N dan setiap aturan menambahkan file, kita akan memiliki 1+2+...+N anggota koleksi.

Untuk mengatasi masalah ini, kami menemukan konsep NestedSet. Ini adalah struktur data yang terdiri dari instance NestedSet lain dan beberapa anggotanya sendiri, sehingga membentuk grafik acyclic yang diarahkan dari kumpulan. Objek ini tidak dapat diubah dan anggotanya dapat di-iterasi. Kita menentukan beberapa urutan iterasi (NestedSet.Order): preorder, postorder, topologi (node selalu muncul setelah ancestor-nya) dan "tidak peduli, tetapi harus sama setiap kali".

Struktur data yang sama disebut depset di Starlark.

Artefak dan Tindakan

Build sebenarnya terdiri dari serangkaian perintah yang perlu dijalankan untuk menghasilkan output yang diinginkan pengguna. Perintah direpresentasikan sebagai instance class Action dan file direpresentasikan sebagai instance class Artifact. Elemen ini diatur dalam grafik acyclic bipartite yang diarahkan dan disebut "grafik tindakan".

Artefak terdiri dari dua jenis: artefak sumber (yang tersedia sebelum Bazel mulai dieksekusi) dan artefak turunan (yang perlu di-build). Artefak turunan sendiri dapat berupa beberapa jenis:

1. **Artefak reguler. **File ini diperiksa keaktualannya dengan menghitung checksum-nya, dengan mtime sebagai pintasan; kami tidak melakukan checksum pada file jika ctime-nya belum berubah.
2. Artefak symlink yang belum terselesaikan. Link ini diperiksa untuk menampilkan data terbaru dengan memanggil readlink(). Tidak seperti artefak biasa, symlink ini dapat menjadi symlink yang menjuntai. Biasanya digunakan jika seseorang kemudian memaketkan beberapa file ke dalam suatu arsip.
3. Artefak pohon. Ini bukan file tunggal, tetapi hierarki direktori. File tersebut diperiksa keaktualannya dengan memeriksa kumpulan file di dalamnya dan kontennya. Nilai ini direpresentasikan sebagai TreeArtifact.
4. Artefak metadata konstan. Perubahan pada artefak ini tidak memicu pembuatan ulang. Ini digunakan secara eksklusif untuk informasi stempel build: kita tidak ingin melakukan build ulang hanya karena waktu saat ini berubah.

Tidak ada alasan mendasar mengapa artefak sumber tidak boleh berupa artefak pohon atau artefak symlink yang belum terselesaikan, hanya saja kita belum mengimplementasikannya (kita harusnya, -- merujuk direktori sumber dalam file BUILD adalah salah satu beberapa masalah kesalahan yang telah lama ada sejak lama pada Bazel; kami memiliki implementasi semacam pekerjaan yang diaktifkan oleh properti JVM BAZEL_TRACK_SOURCE_DIRECTORIES=1)

Jenis Artifact yang penting adalah perantara. Hal ini ditunjukkan oleh instance Artifact yang merupakan output dari MiddlemanAction. Fungsi ini digunakan untuk menangani beberapa hal secara khusus:

• Agregasi perantara digunakan untuk mengelompokkan artefak. Hal ini dilakukan agar jika banyak tindakan menggunakan kumpulan input besar yang sama, kita tidak memiliki tepi dependensi N*M, hanya N+M (digantikan dengan kumpulan bertingkat)
• Menjadwalkan perantara dependensi memastikan bahwa tindakan berjalan sebelum tindakan lainnya. Ini sebagian besar digunakan untuk linting, tetapi juga untuk kompilasi C++ (lihat CcCompilationContext.createMiddleman() untuk penjelasan)
• Perantara runfile digunakan untuk memastikan keberadaan hierarki runfile sehingga tidak perlu bergantung secara terpisah pada manifes output dan setiap artefak yang dirujuk oleh hierarki runfile.

Tindakan paling baik dipahami sebagai perintah yang perlu dijalankan, lingkungan yang diperlukan, dan kumpulan output yang dihasilkan. Hal-hal berikut adalah komponen utama deskripsi tindakan:

• Command line yang perlu dijalankan
• Artefak input yang diperlukan
• Variabel lingkungan yang perlu ditetapkan
• Anotasi yang mendeskripsikan lingkungan (seperti platform) tempatnya harus dijalankan \

Ada juga beberapa kasus khusus lainnya, seperti menulis file yang kontennya diketahui oleh Bazel. Keduanya adalah subclass dari AbstractAction. Sebagian besar tindakan adalah SpawnAction atau StarlarkAction (sama, tindakan ini seharusnya tidak merupakan class terpisah), meskipun Java dan C++ memiliki jenis tindakannya sendiri (JavaCompileAction, CppCompileAction, dan CppLinkAction).

Pada akhirnya, kita ingin memindahkan semuanya ke SpawnAction; JavaCompileAction cukup mirip, tetapi C++ sedikit merupakan kasus khusus karena penguraian file .d dan penyematan pemindaian.

Grafik tindakan sebagian besar "disematkan" ke dalam grafik Skyframe: secara konseptual, eksekusi tindakan direpresentasikan sebagai panggilan ActionExecutionFunction. Pemetaan dari tepi dependensi grafik tindakan ke tepi dependensi Skyframe dijelaskan dalam ActionExecutionFunction.getInputDeps() dan Artifact.key() serta memiliki beberapa pengoptimalan untuk menjaga jumlah tepi Skyframe tetap rendah:

• Artefak turunan tidak memiliki SkyValue-nya sendiri. Sebagai gantinya, Artifact.getGeneratingActionKey() digunakan untuk mengetahui kunci untuk tindakan yang membuatnya
• Set bertingkat memiliki kunci Skyframe-nya sendiri.

Tindakan bersama

Beberapa tindakan dihasilkan oleh beberapa target yang dikonfigurasi; Aturan Starlark lebih terbatas karena hanya diizinkan untuk menempatkan tindakan turunannya ke dalam direktori yang ditentukan oleh konfigurasi dan paketnya (meskipun demikian, aturan dalam paket yang sama dapat bertentangan), tetapi aturan yang diterapkan di Java dapat menempatkan artefak turunan di mana saja.

Hal ini dianggap sebagai kesalahan fitur, tetapi menghilangkannya sangat sulit karena menghasilkan penghematan waktu eksekusi yang signifikan saat, misalnya, file sumber perlu diproses dan file tersebut direferensikan oleh beberapa aturan (handwave-handwave). Hal ini memerlukan biaya beberapa RAM: setiap instance tindakan bersama harus disimpan dalam memori secara terpisah.

Jika dua tindakan menghasilkan file output yang sama, keduanya harus sama persis: memiliki input yang sama, output yang sama, dan menjalankan command line yang sama. Hubungan ekivalensi ini diimplementasikan di Actions.canBeShared() dan diverifikasi antara fase analisis dan eksekusi dengan melihat setiap Action. Hal ini diimplementasikan di SkyframeActionExecutor.findAndStoreArtifactConflicts() dan merupakan salah satu dari beberapa tempat di Bazel yang memerlukan tampilan build "global".

Fase eksekusi

Ini adalah saat Bazel benar-benar mulai menjalankan tindakan build, seperti perintah yang menghasilkan output.

Hal pertama yang dilakukan Bazel setelah fase analisis adalah menentukan Artefak yang perlu dibuat. Logika untuk hal ini dienkode dalam TopLevelArtifactHelper; kurang lebih, ini adalah filesToBuild dari target yang dikonfigurasi pada command line dan konten grup output khusus untuk tujuan eksplisit menyatakan "jika target ini berada di command line, build artefak ini".

Langkah berikutnya adalah membuat root eksekusi. Karena Bazel memiliki opsi untuk membaca paket sumber dari lokasi yang berbeda dalam sistem file (--package_path), Bazel harus menyediakan tindakan yang dieksekusi secara lokal dengan hierarki sumber lengkap. Hal ini ditangani oleh class SymlinkForest dan berfungsi dengan mencatat setiap target yang digunakan dalam fase analisis dan membuat satu hierarki direktori yang membuat symlink setiap paket dengan target yang digunakan dari lokasi sebenarnya. Alternatifnya adalah meneruskan jalur yang benar ke perintah (dengan mempertimbangkan --package_path). Hal ini tidak diinginkan karena:

• Tindakan ini mengubah command line tindakan saat paket dipindahkan dari entri jalur paket ke entri lain (sebelumnya umum terjadi)
• Hal ini menghasilkan command line yang berbeda jika tindakan dijalankan dari jarak jauh dibandingkan jika dijalankan secara lokal
• Hal ini memerlukan transformasi command line khusus untuk alat yang digunakan (pertimbangkan perbedaan antara classpath Java dan jalur penyertaan C++)
• Mengubah command line tindakan akan membatalkan entri cache tindakannya
• --package_path secara bertahap dan terus-menerus tidak digunakan lagi

Kemudian, Bazel mulai menjelajahi grafik tindakan (grafik terarah bipartit yang terdiri dari tindakan serta artefak input dan outputnya) dan menjalankan tindakan. Eksekusi setiap tindakan direpresentasikan oleh instance class SkyValue ActionExecutionValue.

Karena menjalankan tindakan itu mahal, kami memiliki beberapa lapisan penyimpanan dalam cache yang dapat diakses di balik Skyframe:

• ActionExecutionFunction.stateMap berisi data untuk membuat Skyframe memulai ulang ActionExecutionFunction dengan murah
• Cache tindakan lokal berisi data tentang status sistem file
• Sistem eksekusi jarak jauh biasanya juga berisi cache-nya sendiri

Cache tindakan lokal

Cache ini adalah lapisan lain yang berada di belakang Skyframe; meskipun tindakan dijalankan ulang di Skyframe, tindakan tersebut masih dapat menjadi hit di cache tindakan lokal. File ini mewakili status sistem file lokal dan diserialisasi ke disk yang berarti bahwa saat memulai server Bazel baru, Anda bisa mendapatkan hit cache tindakan lokal meskipun grafik Skyframe kosong.

Cache ini diperiksa untuk menemukan hit menggunakan metode ActionCacheChecker.getTokenIfNeedToExecute() .

Berbeda dengan namanya, ini adalah peta dari jalur artefak turunan ke tindakan yang memunculkannya. Tindakan ini dijelaskan sebagai:

1. Kumpulan file input dan output serta checksum-nya
2. "Kunci tindakan"-nya, yang biasanya merupakan command line yang dieksekusi, tetapi secara umum, mewakili semua yang tidak ditangkap oleh checksum file input (seperti untuk FileWriteAction, ini adalah checksum data yang ditulis)

Ada juga "cache tindakan top-down" yang sangat eksperimental dan masih dalam pengembangan, yang menggunakan hash transitif untuk menghindari membuka cache sebanyak mungkin.

Penemuan input dan pemangkasan input

Beberapa tindakan lebih rumit daripada sekadar memiliki kumpulan input. Perubahan pada kumpulan input tindakan memiliki dua bentuk:

• Suatu tindakan dapat menemukan input baru sebelum dieksekusi atau memutuskan bahwa beberapa inputnya sebenarnya tidak diperlukan. Contoh kanonisnya adalah C++, yang lebih baik untuk membuat perkiraan yang matang tentang file header yang digunakan file C++ dari penutupan transitifnya sehingga kita tidak menghendaki setiap file ke eksekutor jarak jauh. Oleh karena itu, kita memiliki opsi untuk tidak mendaftarkan setiap file header sebagai "input", tetapi memindai file sumber untuk menemukan opsi Bazel yang disertakan secara transitif dan hanya menandai file header yang disertakan secara transitif sebagai input yang disertakan sebelumnya.#include
• Suatu tindakan mungkin menyadari bahwa beberapa file tidak digunakan selama eksekusinya. Di C++, ini disebut "file .d": compiler memberi tahu file header mana yang digunakan setelah fakta, dan untuk menghindari rasa malu karena memiliki inkrementalitas yang lebih buruk daripada Make, Bazel memanfaatkan fakta ini. Hal ini menawarkan perkiraan yang lebih baik daripada pemindai include karena bergantung pada compiler.

Ini diimplementasikan menggunakan metode pada Action:

1. Action.discoverInputs() dipanggil. Fungsi ini akan menampilkan kumpulan Artefak bertingkat yang ditentukan sebagai diperlukan. Elemen tersebut harus berupa artefak sumber sehingga tidak ada tepi dependensi dalam grafik tindakan yang tidak memiliki nilai yang setara dalam grafik target yang dikonfigurasi.
2. Tindakan ini dijalankan dengan memanggil Action.execute().
3. Di akhir Action.execute(), tindakan dapat memanggil Action.updateInputs() untuk memberi tahu Bazel bahwa tidak semua inputnya diperlukan. Hal ini dapat menyebabkan build inkremental yang salah jika input yang digunakan dilaporkan sebagai tidak digunakan.

Saat cache tindakan menampilkan hit pada instance Action baru (seperti yang dibuat setelah server dimulai ulang), Bazel memanggil updateInputs() itu sendiri sehingga kumpulan input mencerminkan hasil penemuan dan pemangkasan input yang dilakukan sebelumnya.

Tindakan Starlark dapat memanfaatkan fasilitas untuk mendeklarasikan beberapa input sebagai tidak digunakan menggunakan argumen unused_inputs_list= dari ctx.actions.run().

Berbagai cara untuk menjalankan tindakan: Strategi/ActionContexts

Beberapa tindakan dapat dijalankan dengan cara yang berbeda. Misalnya, command line dapat dijalankan secara lokal, secara lokal tetapi di berbagai jenis sandbox, atau dari jarak jauh. Konsep yang mewujudkan hal ini disebut ActionContext (atau Strategy, karena kita hanya berhasil melakukan penggantian nama setengah jalan...)

Siklus hidup konteks tindakan adalah sebagai berikut:

1. Saat fase eksekusi dimulai, instance BlazeModule akan ditanya konteks tindakan yang mereka miliki. Hal ini terjadi di konstruktor ExecutionTool. Jenis konteks tindakan diidentifikasi oleh instance Class Java yang merujuk ke sub-antarmuka ActionContext dan antarmuka yang harus diimplementasikan oleh konteks tindakan.
2. Konteks tindakan yang sesuai dipilih dari yang tersedia dan diteruskan ke ActionExecutionContext dan BlazeExecutor .
3. Tindakan meminta konteks menggunakan ActionExecutionContext.getContext() dan BlazeExecutor.getStrategy() (seharusnya hanya ada satu cara untuk melakukannya …)

Strategi bebas memanggil strategi lain untuk melakukan tugasnya; hal ini digunakan, misalnya, dalam strategi dinamis yang memulai tindakan secara lokal dan jarak jauh, lalu menggunakan strategi yang selesai lebih dulu.

Salah satu strategi yang penting adalah strategi yang menerapkan proses pekerja persisten (WorkerSpawnStrategy). Idenya adalah bahwa beberapa alat memiliki waktu startup yang lama sehingga harus digunakan kembali di antara tindakan, bukan memulainya lagi untuk setiap tindakan (Hal ini memang mewakili potensi masalah kebenaran, karena Bazel mengandalkan janji proses pekerja bahwa proses tersebut tidak membawa status yang dapat diamati di antara setiap permintaan)

Jika alat berubah, proses pekerja harus dimulai ulang. Apakah pekerja dapat digunakan kembali ditentukan dengan menghitung checksum untuk alat yang digunakan menggunakan WorkerFilesHash. Hal ini bergantung pada mengetahui input tindakan mana yang mewakili bagian alat dan mana yang mewakili input; hal ini ditentukan oleh pembuat Tindakan: Spawn.getToolFiles() dan runfile Spawn dihitung sebagai bagian dari alat.

Informasi selengkapnya tentang strategi (atau konteks tindakan!):

• Informasi tentang berbagai strategi untuk menjalankan tindakan tersedia di sini.
• Informasi tentang strategi dinamis, yaitu strategi yang menjalankan tindakan secara lokal dan jarak jauh untuk melihat mana yang selesai lebih dulu tersedia di sini.
• Informasi tentang seluk-beluk menjalankan tindakan secara lokal tersedia di sini.

Pengelola resource lokal

Bazel dapat menjalankan banyak tindakan secara paralel. Jumlah tindakan lokal yang harus dijalankan secara paralel berbeda-beda dari tindakan ke tindakan: semakin banyak resource yang diperlukan tindakan, semakin sedikit instance yang harus berjalan secara bersamaan untuk menghindari overload pada mesin lokal.

Hal ini diimplementasikan di class ResourceManager: setiap tindakan harus dianotasi dengan estimasi resource lokal yang diperlukan dalam bentuk instance ResourceSet (CPU dan RAM). Kemudian, saat konteks tindakan melakukan sesuatu yang memerlukan resource lokal, konteks tersebut akan memanggil ResourceManager.acquireResources() dan diblokir hingga resource yang diperlukan tersedia.

Deskripsi pengelolaan resource lokal yang lebih mendetail tersedia di sini.

Struktur direktori output

Setiap tindakan memerlukan tempat terpisah di direktori output tempat tindakan tersebut menempatkan output-nya. Lokasi artefak turunan biasanya sebagai berikut:

$EXECROOT/bazel-out/<configuration>/bin/<package>/<artifact name>

Bagaimana nama direktori yang dikaitkan dengan konfigurasi tertentu ditentukan? Ada dua properti yang diinginkan bertentangan:

1. Jika dua konfigurasi bisa muncul pada build yang sama, konfigurasi tersebut harus memiliki direktori yang berbeda agar keduanya dapat memiliki versinya sendiri untuk tindakan yang sama; jika tidak, jika kedua konfigurasi tersebut tidak sepakat, misalnya command line dari tindakan yang menghasilkan file output yang sama, Bazel tidak akan mengetahui tindakan mana yang harus dipilih ("konflik tindakan")
2. Jika dua konfigurasi mewakili "secara kasar" hal yang sama, keduanya harus memiliki nama yang sama sehingga tindakan yang dijalankan di satu konfigurasi dapat digunakan kembali untuk konfigurasi lainnya jika baris perintah cocok: misalnya, perubahan pada opsi command line ke compiler Java tidak boleh menyebabkan tindakan kompilasi C++ dijalankan kembali.

Sejauh ini, kita belum menemukan cara yang prinsipil untuk menyelesaikan masalah ini, yang memiliki kesamaan dengan masalah pemangkasan konfigurasi. Diskusi opsi yang lebih panjang tersedia di sini. Area utama yang bermasalah adalah aturan Starlark (yang penulisnya biasanya tidak sangat memahami Bazel) dan aspek, yang menambahkan dimensi lain ke ruang hal-hal yang dapat menghasilkan file output "sama".

Pendekatan saat ini adalah segmen jalur untuk konfigurasi adalah <CPU>-<compilation mode> dengan berbagai akhiran yang ditambahkan sehingga transisi konfigurasi yang diterapkan di Java tidak menyebabkan konflik tindakan. Selain itu, checksum kumpulan transisi konfigurasi Starlark ditambahkan sehingga pengguna tidak dapat menyebabkan konflik tindakan. Hal ini jauh dari sempurna. Hal ini diterapkan di OutputDirectories.buildMnemonic() dan bergantung pada setiap fragmen konfigurasi yang menambahkan bagiannya sendiri ke nama direktori output.

Pengujian

Bazel memiliki dukungan yang kaya untuk menjalankan pengujian. API ini mendukung:

• Menjalankan pengujian dari jarak jauh (jika backend eksekusi jarak jauh tersedia)
• Menjalankan pengujian beberapa kali secara paralel (untuk mendeflaking atau mengumpulkan data waktu)
• Pengujian sharding (membagi kasus pengujian dalam pengujian yang sama di beberapa proses untuk kecepatan)
• Menjalankan ulang pengujian yang tidak stabil
• Mengelompokkan pengujian ke dalam rangkaian pengujian

Pengujian adalah target yang dikonfigurasi secara reguler yang memiliki TestProvider, yang menjelaskan cara pengujian harus dijalankan:

• Artefak yang proses build-nya menghasilkan pengujian yang dijalankan. Ini adalah file "status cache" yang berisi pesan TestResultData serial
• Frekuensi pengujian harus dijalankan
• Jumlah shard yang akan dibagi untuk pengujian
• Beberapa parameter tentang cara pengujian harus dijalankan (seperti waktu tunggu pengujian)

Menentukan pengujian yang akan dijalankan

Menentukan pengujian yang dijalankan adalah proses yang rumit.

Pertama, selama penguraian pola target, rangkaian pengujian diperluas secara rekursif. Ekspansi diimplementasikan di TestsForTargetPatternFunction. Hal yang agak mengejutkan adalah jika rangkaian pengujian tidak mendeklarasikan pengujian, rangkaian pengujian tersebut merujuk pada setiap pengujian dalam paketnya. Hal ini diterapkan di Package.beforeBuild() dengan menambahkan atribut implisit yang disebut $implicit_tests ke aturan suite pengujian.

Kemudian, pengujian difilter berdasarkan ukuran, tag, waktu tunggu, dan bahasa sesuai dengan opsi command line. Hal ini diimplementasikan di TestFilter dan dipanggil dari TargetPatternPhaseFunction.determineTests() selama penguraian target dan hasilnya dimasukkan ke TargetPatternPhaseValue.getTestsToRunLabels(). Alasan atribut aturan yang dapat difilter tidak dapat dikonfigurasi adalah karena hal ini terjadi sebelum fase analisis, sehingga konfigurasi tidak tersedia.

Hal ini kemudian diproses lebih lanjut di BuildView.createResult(): target yang analisisnya gagal akan difilter dan pengujian akan dibagi menjadi pengujian eksklusif dan non-eksklusif. Kemudian dimasukkan ke dalam AnalysisResult, yang merupakan cara ExecutionTool mengetahui pengujian yang akan dijalankan.

Untuk memberikan transparansi pada proses yang rumit ini, operator kueri tests() (diterapkan di TestsFunction) tersedia untuk mengetahui pengujian mana yang dijalankan saat target tertentu ditentukan di command line. Sayangnya, ini adalah penerapan ulang, sehingga mungkin menyimpang dari hal di atas dengan beberapa cara yang halus.

Menjalankan pengujian

Cara pengujian dijalankan adalah dengan meminta artefak status cache. Tindakan ini kemudian menghasilkan eksekusi TestRunnerAction, yang pada akhirnya memanggil TestActionContext yang dipilih oleh opsi command line --test_strategy yang menjalankan pengujian dengan cara yang diminta.

Pengujian dijalankan sesuai dengan protokol rumit yang menggunakan variabel lingkungan untuk membedakan pengujian dengan apa yang diharapkan darinya. Deskripsi mendetail tentang hal yang diharapkan Bazel dari pengujian dan hal yang dapat diharapkan pengujian dari Bazel tersedia di sini. Secara sederhana, kode keluar 0 berarti berhasil, yang lainnya berarti gagal.

Selain file status cache, setiap proses pengujian menghasilkan sejumlah file lain. Log tersebut ditempatkan di "direktori log pengujian" yang merupakan subdirektori yang disebut testlogs dari direktori output konfigurasi target:

• test.xml, file XML bergaya JUnit yang menjelaskan setiap kasus pengujian dalam shard pengujian
• test.log, output konsol pengujian. stdout dan stderr tidak dipisah.
• test.outputs, "direktori output yang tidak dideklarasikan"; ini digunakan oleh pengujian yang ingin menghasilkan file selain yang dicetak ke terminal.

Ada dua hal yang dapat terjadi selama eksekusi uji yang tidak dapat terjadi selama membangun target reguler: eksekusi uji eksklusif dan streaming output.

Beberapa pengujian perlu dijalankan dalam mode eksklusif, misalnya tidak paralel dengan pengujian lainnya. Hal ini dapat diperoleh dengan menambahkan tags=["exclusive"] ke aturan pengujian atau menjalankan pengujian dengan --test_strategy=exclusive. Setiap pengujian eksklusif dijalankan oleh pemanggilan Skyframe terpisah yang meminta eksekusi pengujian setelah build "utama". Hal ini diterapkan di SkyframeExecutor.runExclusiveTest().

Tidak seperti tindakan reguler, yang output terminalnya di-dump saat tindakan selesai, pengguna dapat meminta output pengujian untuk di-streaming sehingga mereka mendapatkan informasi tentang progres pengujian yang berjalan lama. Hal ini ditentukan oleh opsi command line --test_output=streamed dan menyiratkan eksekusi uji eksklusif sehingga output dari berbagai pengujian tidak diselingi.

Ini diterapkan di class StreamedTestOutput yang dinamai dengan tepat dan berfungsi dengan melakukan polling perubahan pada file test.log pengujian yang dimaksud dan membuang byte baru ke terminal tempat aturan Bazel.

Hasil pengujian yang dijalankan tersedia di bus peristiwa dengan mengamati berbagai peristiwa (seperti TestAttempt, TestResult, atau TestingCompleteEvent). Hasil tersebut di-dump ke Build Event Protocol dan ditampilkan ke konsol oleh AggregatingTestListener.

Koleksi cakupan

Cakupan dilaporkan oleh pengujian dalam format LCOV dalam file bazel-testlogs/$PACKAGE/$TARGET/coverage.dat .

Untuk mengumpulkan cakupan, setiap eksekusi pengujian digabungkan dalam skrip yang disebut collect_coverage.sh .

Skrip ini menyiapkan lingkungan pengujian untuk mengaktifkan pengumpulan cakupan dan menentukan tempat file cakupan ditulis oleh runtime cakupan. Kemudian sistem menjalankan pengujian. Pengujian itu sendiri dapat menjalankan beberapa subproses dan terdiri dari bagian yang ditulis dalam beberapa bahasa pemrograman yang berbeda (dengan runtime pengumpulan cakupan terpisah). Skrip wrapper bertanggung jawab untuk mengonversi file yang dihasilkan ke format LCOV jika diperlukan, dan menggabungkannya menjadi satu file.

Interposisi collect_coverage.sh dilakukan oleh strategi pengujian dan memerlukan collect_coverage.sh berada di input pengujian. Hal ini dilakukan oleh atribut implisit :coverage_support yang di-resolve ke nilai flag konfigurasi --coverage_support (lihat TestConfiguration.TestOptions.coverageSupport)

Beberapa bahasa melakukan instrumentasi offline, yang berarti instrumentasi cakupan ditambahkan pada waktu kompilasi (seperti C++) dan bahasa lainnya melakukan instrumentasi online, yang berarti instrumentasi cakupan ditambahkan pada waktu eksekusi.

Konsep inti lainnya adalah cakupan dasar pengukuran. Ini adalah cakupan library, biner, atau pengujian jika tidak ada kode di dalamnya yang dijalankan. Masalah yang dipecahkan adalah jika Anda ingin menghitung cakupan pengujian untuk biner, menggabungkan cakupan semua pengujian saja tidak cukup karena mungkin ada kode dalam biner yang tidak dikaitkan ke pengujian apa pun. Oleh karena itu, yang kita lakukan adalah memunculkan file cakupan untuk setiap biner yang hanya berisi file yang cakupannya kita kumpulkan tanpa baris yang tercakup. File cakupan dasar pengukuran untuk target ada di bazel-testlogs/$PACKAGE/$TARGET/baseline_coverage.dat . Flag ini juga dibuat untuk biner dan library, selain untuk pengujian apakah Anda meneruskan flag --nobuild_tests_only ke Bazel.

Cakupan dasar pengukuran saat ini rusak.

Kami melacak dua grup file untuk pengumpulan cakupan untuk setiap aturan: kumpulan file berinstrumen dan kumpulan file metadata instrumentasi.

Kumpulan file berinstrumen hanyalah kumpulan file yang akan diinstrumentasi. Untuk runtime cakupan online, ini dapat digunakan saat runtime untuk menentukan file mana yang akan diinstrumentasi. Cakupan juga digunakan untuk menerapkan cakupan dasar.

Kumpulan file metadata instrumentasi adalah kumpulan file tambahan yang diperlukan pengujian untuk membuat file LCOV yang diperlukan Bazel. Dalam praktiknya, ini terdiri dari file khusus runtime; misalnya, gcc memunculkan file .gcno selama kompilasi. Ini ditambahkan ke kumpulan input tindakan pengujian jika mode cakupan diaktifkan.

Apakah cakupan sedang dikumpulkan atau tidak disimpan di BuildConfiguration. Hal ini berguna karena merupakan cara mudah untuk mengubah tindakan pengujian dan grafik tindakan bergantung pada bit ini, tetapi juga berarti bahwa jika bit ini dibalik, semua target perlu dianalisis ulang (beberapa bahasa, seperti C++ memerlukan opsi compiler yang berbeda untuk memunculkan kode yang dapat mengumpulkan cakupan, sehingga sedikit mengurangi masalah ini, karena analisis ulang tetap diperlukan).

File dukungan cakupan bergantung pada label dalam dependensi implisit sehingga dapat diganti oleh kebijakan pemanggilan, yang memungkinkan file tersebut berbeda di antara berbagai versi Bazel. Idealnya, perbedaan ini akan dihapus, dan kami menstandarkan salah satunya.

Kita juga membuat "laporan cakupan" yang menggabungkan cakupan yang dikumpulkan untuk setiap pengujian dalam pemanggilan Bazel. Hal ini ditangani oleh CoverageReportActionFactory dan dipanggil dari BuildView.createResult() . Alat ini mendapatkan akses ke alat yang diperlukan dengan melihat atribut :coverage_report_generator dari pengujian pertama yang dijalankan.

Mesin kueri

Bazel memiliki bahasa kecil yang digunakan untuk menanyakan berbagai hal tentang berbagai grafik. Jenis kueri berikut disediakan:

• bazel query digunakan untuk menyelidiki grafik target
• bazel cquery digunakan untuk menyelidiki grafik target yang dikonfigurasi
• bazel aquery digunakan untuk menyelidiki grafik tindakan

Masing-masing ini diimplementasikan dengan membuat subclass AbstractBlazeQueryEnvironment. Fungsi kueri tambahan lainnya dapat dilakukan dengan membuat subclass QueryFunction. Untuk mengizinkan hasil kueri streaming, alih-alih mengumpulkannya ke beberapa struktur data, query2.engine.Callback diteruskan ke QueryFunction, yang memanggilnya untuk hasil yang ingin ditampilkan.

Hasil kueri dapat ditampilkan dengan berbagai cara: label, label dan class aturan, XML, protobuf, dan sebagainya. Fungsi ini diimplementasikan sebagai subclass OutputFormatter.

Persyaratan halus dari beberapa format output kueri (proto, pasti) adalah bahwa Bazel perlu memunculkan _semua _informasi yang disediakan pemuatan paket sehingga seseorang dapat membandingkan output dan menentukan apakah target tertentu telah berubah. Akibatnya, nilai atribut harus dapat diserialisasi. Itulah sebabnya hanya ada sedikit jenis atribut tanpa atribut yang memiliki nilai Starlark yang kompleks. Solusi yang biasa digunakan adalah menggunakan label, dan melampirkan informasi kompleks ke aturan dengan label tersebut. Ini bukan solusi yang sangat memuaskan dan akan sangat baik jika persyaratan ini dicabut.

Sistem modul

Bazel dapat diperluas dengan menambahkan modul ke dalamnya. Setiap modul harus membuat subclass BlazeModule (namanya adalah peninggalan sejarah Bazel saat dulunya disebut Blaze) dan mendapatkan informasi tentang berbagai peristiwa selama eksekusi perintah.

Bazel sebagian besar digunakan untuk menerapkan berbagai bagian fungsi "non-inti" yang hanya diperlukan oleh beberapa versi Bazel (seperti yang kami gunakan di Google):

• Antarmuka ke sistem eksekusi jarak jauh
• Perintah baru

Rangkaian titik ekstensi yang ditawarkan BlazeModule agak berbahaya. Jangan gunakannya sebagai contoh prinsip desain yang baik.

{i>Bus<i} acara

Cara utama BlazeModules berkomunikasi dengan bagian Bazel lainnya adalah melalui bus peristiwa (EventBus): instance baru dibuat untuk setiap build, berbagai bagian Bazel dapat memposting peristiwa ke dalamnya, dan modul dapat mendaftarkan pemroses untuk peristiwa yang diminati. Misalnya, hal-hal berikut ditampilkan sebagai peristiwa:

• Daftar target build yang akan dibuat telah ditentukan (TargetParsingCompleteEvent)
• Konfigurasi tingkat atas telah ditentukan (BuildConfigurationEvent)
• Target dibuat, berhasil atau tidak (TargetCompleteEvent)
• Pengujian dijalankan (TestAttempt, TestSummary)

Beberapa peristiwa ini diwakili di luar Bazel dalam Build Event Protocol (yaitu BuildEvent). Hal ini memungkinkan tidak hanya BlazeModule, tetapi juga hal-hal di luar proses Bazel untuk mengamati build. Dapat diakses sebagai file yang berisi pesan protokol, atau Bazel dapat terhubung ke server (disebut Build Event Service) untuk melakukan streaming peristiwa.

Hal ini diterapkan dalam paket Java build.lib.buildeventservice dan build.lib.buildeventstream.

Repositori eksternal

Meskipun Bazel awalnya dirancang untuk digunakan dalam monorepo (hierarki sumber tunggal yang berisi semua yang perlu di-build), Bazel berada di dunia yang tidak selalu benar. "Repositori eksternal" adalah abstraksi yang digunakan untuk menjembatani kedua dunia ini: repositori ini mewakili kode yang diperlukan untuk build, tetapi tidak ada dalam hierarki sumber utama.

File WORKSPACE

Kumpulan repositori eksternal ditentukan dengan mengurai file WORKSPACE. Misalnya, deklarasi seperti ini:

    local_repository(name="foo", path="/foo/bar")

Hasil di repositori bernama @foo tersedia. Yang membuat hal ini menjadi rumit adalah seseorang dapat menentukan aturan repositori baru dalam file Starlark, yang kemudian dapat digunakan untuk memuat kode Starlark baru, yang dapat digunakan untuk menentukan aturan repositori baru dan seterusnya…

Untuk menangani kasus ini, penguraian file WORKSPACE (dalam WorkspaceFileFunction) dibagi menjadi beberapa bagian yang dibatasi oleh pernyataan load(). Indeks bagian ditunjukkan oleh WorkspaceFileKey.getIndex() dan menghitung WorkspaceFileFunction hingga indeks X berarti mengevaluasinya hingga pernyataan load() ke-X.

Mengambil repositori

Sebelum kode repositori tersedia untuk Bazel, kode tersebut harus diambil. Hal ini menyebabkan Bazel membuat direktori dalam $OUTPUT_BASE/external/<repository name>.

Pengambilan repositori dilakukan dalam langkah-langkah berikut:

1. PackageLookupFunction menyadari bahwa diperlukan repositori dan membuat RepositoryName sebagai SkyKey yang memanggil RepositoryLoaderFunction
2. RepositoryLoaderFunction meneruskan permintaan ke RepositoryDelegatorFunction karena alasan yang tidak jelas (kode tersebut menyatakan bahwa hal ini dilakukan untuk menghindari download ulang jika Skyframe dimulai ulang, tetapi ini bukan alasan yang sangat kuat)
3. RepositoryDelegatorFunction mengetahui aturan repositori yang diminta untuk diambil dengan melakukan iterasi pada bagian file WORKSPACE hingga repositori yang diminta ditemukan
4. RepositoryFunction yang sesuai ditemukan yang mengimplementasikan pengambilan repositori; ini adalah implementasi Starlark repositori atau peta hard code untuk repositori yang diimplementasikan di Java.

Ada berbagai lapisan caching karena mengambil repositori bisa sangat mahal:

1. Ada cache untuk file yang didownload yang diberi kunci oleh checksumnya (RepositoryCache). Hal ini mengharuskan checksum tersedia di file WORKSPACE, tetapi hal ini baik untuk hermetisitas. Hal ini digunakan bersama oleh setiap instance server Bazel di workstation yang sama, terlepas dari ruang kerja atau basis output tempat mereka berjalan.
2. "File penanda" ditulis untuk setiap repositori pada $OUTPUT_BASE/external yang berisi checksum aturan yang digunakan untuk mengambilnya. Jika server Bazel dimulai ulang, tetapi checksum tidak berubah, checksum tidak akan diambil lagi. Hal ini diimplementasikan di RepositoryDelegatorFunction.DigestWriter .
3. Opsi command line --distdir menetapkan cache lain yang digunakan untuk mencari artefak yang akan didownload. Hal ini berguna di setelan perusahaan tempat Bazel tidak boleh mengambil hal-hal acak dari Internet. Ini diimplementasikan oleh DownloadManager.

Setelah repositori didownload, artefak di dalamnya akan diperlakukan sebagai artefak sumber. Hal ini menimbulkan masalah karena Bazel biasanya memeriksa keaktualan artefak sumber dengan memanggil stat() pada artefak tersebut, dan artefak ini juga dibuat tidak valid saat definisi repositori tempatnya berada berubah. Dengan demikian, FileStateValue untuk artefak di repositori eksternal harus bergantung pada repositori eksternalnya. Proses ini ditangani oleh ExternalFilesHelper.

Pemetaan repositori

Terkadang beberapa repositori ingin bergantung pada repositori yang sama, tetapi dalam versi yang berbeda (ini adalah contoh "masalah dependensi berlian"). Misalnya, jika dua biner dalam repositori terpisah dalam build ingin bergantung pada Guava, keduanya mungkin akan merujuk ke Guava dengan label yang dimulai dari @guava// dan mengharapkannya untuk berarti versi yang berbeda.

Oleh karena itu, Bazel memungkinkan pengguna memetakan ulang label repositori eksternal sehingga string @guava// dapat merujuk ke satu repositori Guava (seperti @guava1//) di repositori satu biner dan repositori Guava lainnya (seperti @guava2//) repositori yang lain.

Atau, ini juga dapat digunakan untuk menggabungkan berlian. Jika repositori bergantung pada @guava1//, dan repositori lainnya bergantung pada @guava2//, pemetaan repositori memungkinkan satu repositori untuk memetakan ulang kedua repositori agar menggunakan repositori @guava// kanonis.

Pemetaan ditentukan dalam file WORKSPACE sebagai atribut repo_mapping dari setiap definisi repositori. Kemudian, objek ini akan muncul di Skyframe sebagai anggota WorkspaceFileValue, yang ditautkan ke:

• Package.Builder.repositoryMapping yang digunakan untuk mengubah atribut bernilai label aturan dalam paket oleh RuleClass.populateRuleAttributeValues()
• Package.repositoryMapping yang digunakan dalam fase analisis (untuk menyelesaikan hal-hal seperti $(location) yang tidak diurai dalam fase pemuatan)
• BzlLoadFunction untuk me-resolve label dalam pernyataan load()

Bit JNI

Server Bazel sebagian besar ditulis dalam Java. Pengecualian adalah bagian yang tidak dapat dilakukan Java sendiri atau tidak dapat dilakukan sendiri saat kita menerapkannya. Hal ini sebagian besar terbatas pada interaksi dengan sistem file, kontrol proses, dan berbagai hal tingkat rendah lainnya.

Kode C++ berada di src/main/native dan class Java dengan metode native adalah:

• NativePosixFiles dan NativePosixFileSystem
• ProcessUtils
• WindowsFileOperations dan WindowsFileProcesses
• com.google.devtools.build.lib.platform

Output konsol

Memancarkan output konsol tampaknya merupakan hal yang sederhana, tetapi pertemuan untuk menjalankan beberapa proses (terkadang jarak jauh), caching yang terperinci, keinginan untuk memiliki output terminal yang bagus dan penuh warna, serta memiliki server yang berjalan lama membuatnya menjadi tidak mudah.

Tepat setelah panggilan RPC masuk dari klien, dua instance RpcOutputStream dibuat (untuk stdout dan stderr) yang meneruskan data yang dicetak ke klien. Kemudian, keduanya digabungkan dalam OutErr (pasangan (stdout, stderr)). Apa pun yang perlu dicetak di konsol akan melalui aliran ini. Kemudian, streaming ini akan diserahkan ke BlazeCommandDispatcher.execExclusively().

Output secara default dicetak dengan urutan escape ANSI. Jika tidak diinginkan (--color=no), atribut tersebut akan dihapus oleh AnsiStrippingOutputStream. Selain itu, System.out dan System.err dialihkan ke aliran output ini. Hal ini agar informasi proses debug dapat dicetak menggunakan System.err.println() dan tetap muncul di output terminal klien (yang berbeda dengan server). Pastikan bahwa jika proses menghasilkan output biner (seperti bazel query --output=proto), tidak ada penggabungan stdout.

Pesan singkat (error, peringatan, dan sejenisnya) dinyatakan melalui antarmuka EventHandler. Secara khusus, ini berbeda dengan yang diposting ke EventBus (ini membingungkan). Setiap Event memiliki EventKind (error, peringatan, info, dan beberapa lainnya) serta mungkin memiliki Location (tempat dalam kode sumber yang menyebabkan peristiwa terjadi).

Beberapa implementasi EventHandler menyimpan peristiwa yang diterimanya. Ini digunakan untuk memutar ulang informasi ke UI yang disebabkan oleh berbagai jenis pemrosesan yang di-cache, misalnya, peringatan yang dikeluarkan oleh target yang dikonfigurasi dan di-cache.

Beberapa EventHandler juga memungkinkan postingan peristiwa yang pada akhirnya sampai ke bus peristiwa (Event reguler _tidak _muncul di sana). Ini adalah implementasi ExtendedEventHandler dan penggunaan utamanya adalah untuk memutar ulang peristiwa EventBus yang di-cache. Semua peristiwa EventBus ini mengimplementasikan Postable, tetapi tidak semua yang diposting ke EventBus harus mengimplementasikan antarmuka ini; hanya peristiwa yang di-cache oleh ExtendedEventHandler (akan lebih baik dan sebagian besar hal melakukannya; meskipun tidak diterapkan)

Output terminal sebagian besar dikeluarkan melalui UiEventHandler, yang bertanggung jawab atas semua pemformatan output yang menarik dan pelaporan progres yang dilakukan Bazel. Model ini memiliki dua input:

• Bus peristiwa
• Aliran peristiwa yang disalurkan ke dalamnya melalui Reporter

Satu-satunya koneksi langsung yang dimiliki mesin eksekusi perintah (misalnya, bagian lain dari Bazel) ke aliran RPC ke klien adalah melalui Reporter.getOutErr(), yang memungkinkan akses langsung ke aliran ini. Ini hanya digunakan saat perintah perlu membuang kemungkinan data biner dalam jumlah besar (seperti bazel query).

Membuat profil Bazel

Bazel adalah perangkat yang cepat. Bazel juga lambat, karena build cenderung tumbuh sampai hanya pada bagian yang bisa ditanggung. Karena alasan ini, Bazel menyertakan profiler yang dapat digunakan untuk membuat profil build dan Bazel itu sendiri. Class ini diterapkan dalam class yang diberi nama Profiler. Fungsi ini diaktifkan secara default, meskipun hanya merekam data ringkas sehingga overhead-nya dapat ditoleransi; command line --record_full_profiler_data membuatnya merekam semua yang dapat dilakukannya.

Alat ini menghasilkan profil dalam format profiler Chrome; sebaiknya dilihat di Chrome. Model datanya adalah tumpukan tugas: seseorang dapat memulai tugas dan mengakhiri tugas, dan tugas tersebut seharusnya disusun bertingkat dengan rapi. Setiap thread Java mendapatkan stack tugasnya sendiri. TODO: Bagaimana cara kerjanya dengan tindakan dan gaya penerusan lanjutan?

Profiler dimulai dan dihentikan di BlazeRuntime.initProfiler() dan BlazeRuntime.afterCommand() dan mencoba aktif selama sempat sehingga kita dapat membuat profil semuanya. Untuk menambahkan sesuatu ke profil, panggil Profiler.instance().profile(). Fungsi ini menampilkan Closeable, yang penutupannya mewakili akhir tugas. Sebaiknya digunakan dengan pernyataan try-with-resources.

Kita juga melakukan pembuatan profil memori dasar di MemoryProfiler. Fitur ini juga selalu aktif dan sebagian besar mencatat ukuran heap maksimum dan perilaku GC.

Menguji Bazel

Bazel memiliki dua jenis pengujian utama: pengujian yang mengamati Bazel sebagai "kotak hitam" dan pengujian yang hanya menjalankan fase analisis. Kita menyebut yang pertama sebagai "pengujian integrasi" dan yang kedua sebagai "pengujian unit", meskipun keduanya lebih mirip dengan pengujian integrasi yang kurang terintegrasi. Kami juga memiliki beberapa pengujian unit yang sebenarnya, yang diperlukan.

Dari pengujian integrasi, kita memiliki dua jenis:

1. Yang diimplementasikan menggunakan framework pengujian bash yang sangat rumit di src/test/shell
2. One diimplementasikan di Java. Ini diimplementasikan sebagai subclass BuildIntegrationTestCase

BuildIntegrationTestCase adalah framework pengujian integrasi yang lebih disukai karena dilengkapi dengan baik untuk sebagian besar skenario pengujian. Sebagai framework Java, framework ini menyediakan kemampuan debug dan integrasi yang lancar dengan banyak alat pengembangan umum. Ada banyak contoh class BuildIntegrationTestCase dalam repositori Bazel.

Pengujian analisis diimplementasikan sebagai subclass BuildViewTestCase. Ada sistem file awal yang dapat Anda gunakan untuk menulis file BUILD, lalu berbagai metode helper dapat meminta target yang dikonfigurasi, mengubah konfigurasi, dan menyatakan berbagai hal tentang hasil analisis.