Ensiklopedia uji

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.
Laporkan masalah Lihat sumber

Spesifikasi lengkap lingkungan eksekusi uji.

Latar belakang

Bahasa Bazel BUILD menyertakan aturan yang dapat digunakan untuk menentukan program pengujian otomatis dalam banyak bahasa.

Pengujian dijalankan menggunakan bazel test.

Pengguna juga dapat menjalankan biner pengujian secara langsung. Hal ini diizinkan, tetapi tidak didukung, karena pemanggilan tersebut tidak akan mematuhi mandat yang dijelaskan di bawah ini.

Pengujian harus bersifat hertetik: yaitu, yang hanya boleh mengakses resource yang memiliki dependensi yang dideklarasikan. Jika pengujian tidak hermetic dengan benar, pengujian tidak memberikan hasil yang dapat direproduksi secara historis. Hal ini dapat menjadi masalah yang signifikan untuk temuan penyebab (menentukan perubahan mana yang merusak pengujian), auditabilitas teknik rilis, dan isolasi resource pengujian (framework pengujian otomatis tidak harus melakukan DDOS pada server karena beberapa pengujian berbicara dengannya).

Tujuan

Tujuan halaman ini adalah untuk secara resmi menetapkan lingkungan runtime dan perilaku yang diharapkan dari pengujian Bazel. Hal ini juga akan memberlakukan persyaratan pada runner pengujian dan sistem build.

Spesifikasi lingkungan pengujian membantu penulis pengujian menghindari ketergantungan pada perilaku yang tidak ditentukan, sehingga memberikan infrastruktur lebih banyak kebebasan untuk membuat perubahan implementasi. Spesifikasi ini memperketat beberapa lubang yang saat ini memungkinkan banyak pengujian lulus meskipun tidak hermetik, deterministik, dan reentrant dengan benar.

Halaman ini dimaksudkan agar bersifat normatif dan otoritatif. Jika spesifikasi ini dan perilaku penerapan runner pengujian tidak setuju, spesifikasi akan diutamakan.

Spesifikasi yang Diusulkan

Kata kunci "HARUS", "HARUS TIDAK", "WAJIB", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", dan "OPTIONAL" harus ditafsirkan seperti yang dijelaskan dalam IETF RFC 2119.

Tujuan pengujian

Tujuan pengujian Bazel adalah untuk mengonfirmasi beberapa properti file sumber yang diperiksa ke dalam repositori. (Di halaman ini, "file sumber" mencakup data pengujian, output emas, dan semua data lainnya yang disimpan dalam kontrol versi.) Satu pengguna menulis pengujian untuk menyatakan invarian yang diharapkan akan dipertahankan. Pengguna lain menjalankan pengujian di lain waktu untuk memeriksa apakah invarian telah rusak. Jika pengujian bergantung pada variabel selain file sumber (non-hermetik), nilainya akan berkurang, karena pengguna kemudian tidak dapat memastikan perubahan yang mereka lakukan karena kesalahan saat pengujian berhenti lulus.

Oleh karena itu, hasil pengujian hanya boleh bergantung pada:

  • file sumber yang pengujiannya memiliki dependensi yang dideklarasikan
  • produk sistem build tempat pengujian memiliki dependensi yang dideklarasikan
  • resource yang perilakunya dijamin oleh runner pengujian akan tetap konstan

Saat ini, perilaku tersebut tidak diterapkan. Namun, test runner berhak menambahkan penerapan tersebut di masa mendatang.

Peran sistem build

Aturan pengujian serupa dengan aturan biner, yang masing-masing harus menghasilkan program yang dapat dieksekusi. Untuk beberapa bahasa, ini adalah program stub yang menggabungkan harness khusus bahasa dengan kode pengujian. Aturan pengujian juga harus menghasilkan output lain. Selain untuk pengujian utama yang dapat dijalankan, runner pengujian akan memerlukan manifes runfiles, file input yang harus disediakan untuk pengujian pada waktu proses, dan mungkin memerlukan informasi tentang jenis, ukuran, dan tag pengujian.

Sistem build dapat menggunakan runfile untuk mengirimkan kode serta data. (Hal ini dapat digunakan sebagai pengoptimalan untuk membuat setiap biner pengujian lebih kecil dengan membagikan file di seluruh pengujian, seperti melalui penggunaan penautan dinamis.) Sistem build harus memastikan bahwa file yang dapat dieksekusi yang dihasilkan memuat file ini melalui image runfile yang disediakan oleh test runner, bukan ke referensi yang di-hardcode ke lokasi absolut di pohon output atau sumber.

Peran test runner

Dari sudut pandang runner pengujian, setiap pengujian adalah program yang dapat dipanggil dengan execve(). Mungkin ada cara lain untuk menjalankan pengujian; misalnya, IDE mungkin mengizinkan eksekusi pengujian Java dalam proses. Namun, hasil menjalankan pengujian sebagai proses yang berdiri sendiri harus dianggap otoritatif. Jika proses pengujian berjalan hingga selesai dan berakhir secara normal dengan kode keluar nol, pengujian akan lulus. Hasil lainnya akan dianggap gagal pengujian. Secara khusus, menulis salah satu string PASS atau FAIL ke stdout tidak memiliki signifikansi bagi runner pengujian.

Jika pengujian memakan waktu terlalu lama untuk dijalankan, melebihi batas resource, atau runner pengujian mendeteksi perilaku terlarang, pengujian dapat memilih untuk menghentikan pengujian dan memperlakukan pengujian sebagai gagal. Runner tidak boleh melaporkan pengujian sebagai lulus setelah mengirim sinyal ke proses pengujian atau turunan darinya.

Seluruh target pengujian (bukan metode atau pengujian individual) diberi waktu terbatas untuk berjalan sampai selesai. Batas waktu untuk pengujian didasarkan pada atribut timeout-nya berdasarkan tabel berikut:

timeout Batas Waktu (dtk)
video singkat 60
longgar 300
long 900
abadi 3.600

Pengujian yang tidak secara eksplisit menentukan waktu tunggu memiliki satu tersirat berdasarkan size pengujian sebagai berikut:

ukuran Label waktu tunggu tersirat
small video singkat
medium longgar
large long
sangat besar abadi

Pengujian "besar" tanpa setelan waktu tunggu eksplisit akan dialokasikan 900 detik. Pengujian "sedang" dengan waktu tunggu "pendek" akan dialokasikan 60 detik.

Tidak seperti timeout, size juga menentukan asumsi puncak penggunaan resource lain (seperti RAM) saat menjalankan pengujian secara lokal, seperti yang dijelaskan dalam Definisi umum.

Semua kombinasi label size dan timeout adalah legal, sehingga pengujian "sangat besar" dapat dideklarasikan memiliki waktu tunggu "pendek". Mungkin akan melakukan hal yang sangat mengerikan dengan sangat cepat.

Pengujian dapat segera berubah terlepas dari waktu tunggu. Pengujian tidak dikenai sanksi atas waktu tunggu yang berlebihan, meskipun peringatan mungkin dikeluarkan: secara umum Anda harus menetapkan waktu tunggu seketat mungkin tanpa menimbulkan hambatan.

Waktu tunggu pengujian dapat diganti dengan tanda bazel --test_timeout saat berjalan secara manual dalam kondisi yang diketahui lambat. Nilai --test_timeout dalam hitungan detik. Misalnya, --test_timeout=120 menetapkan waktu tunggu pengujian menjadi dua menit.

Ada juga batas bawah yang direkomendasikan untuk waktu tunggu pengujian sebagai berikut:

timeout Waktu minimum (dtk)
video singkat 0
longgar 30
long 300
abadi 900

Misalnya, jika pengujian "sedang" selesai dalam 5,5 d, pertimbangkan untuk menyetel timeout = "short" atau size = "small". Penggunaan opsi command line --test_verbose_timeout_warnings bazel akan menampilkan pengujian yang ukuran yang ditentukan terlalu besar.

Ukuran dan waktu tunggu pengujian ditentukan dalam file BUILD sesuai dengan spesifikasi di sini. Jika tidak ditentukan, ukuran pengujian akan ditetapkan secara default ke "medium".

Jika proses utama pengujian keluar, tetapi beberapa turunannya masih berjalan, pelari pengujian harus menganggap proses tersebut selesai dan menghitungnya sebagai berhasil atau gagal berdasarkan kode keluar yang diamati dari proses utama. Test runner dapat menghentikan proses yang terpisah. Pengujian tidak boleh membocorkan proses dengan cara ini.

Sharding pengujian

Pengujian dapat diparalelkan melalui sharding pengujian. Lihat --test_sharding_strategy dan shard_count untuk mengaktifkan sharding pengujian. Jika sharding diaktifkan, runner pengujian akan diluncurkan satu kali per shard. Variabel lingkungan TEST_TOTAL_SHARDS adalah jumlah shard, dan TEST_SHARD_INDEX adalah indeks shard, mulai dari 0. Pelari menggunakan informasi ini untuk memilih pengujian mana yang akan dijalankan - misalnya, dengan menggunakan strategi round-robin. Tidak semua runner pengujian mendukung shard. Jika runner mendukung sharding, runner harus membuat atau mengupdate tanggal terakhir diubah dari file yang ditentukan oleh TEST_SHARD_STATUS_FILE. Jika tidak, Bazel akan menganggap bahwa model ini tidak mendukung sharding dan tidak akan meluncurkan runner tambahan.

Kondisi awal

Saat menjalankan pengujian, runner pengujian harus menetapkan kondisi awal tertentu.

Test runner harus memanggil setiap pengujian dengan jalur ke file yang dapat dieksekusi di argv[0]. Jalur ini harus relatif dan berada di bawah direktori pengujian saat ini (yang ada di hierarki runfiles, lihat di bawah). Runner pengujian tidak boleh meneruskan argumen lain ke pengujian kecuali pengguna memintanya secara eksplisit.

Blok lingkungan awal harus disusun sebagai berikut:

Variabel Nilai Status
HOME nilai $TEST_TMPDIR direkomendasikan
LANG tidak disetel wajib
LANGUAGE tidak disetel wajib
LC_ALL tidak disetel wajib
LC_COLLATE tidak disetel wajib
LC_CTYPE tidak disetel wajib
LC_MESSAGES tidak disetel wajib
LC_MONETARY tidak disetel wajib
LC_NUMERIC tidak disetel wajib
LC_TIME tidak disetel wajib
LD_LIBRARY_PATH daftar direktori yang dipisahkan titik dua yang berisi library bersama opsional
JAVA_RUNFILES nilai $TEST_SRCDIR tidak digunakan lagi
LOGNAME nilai $USER wajib
PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. direkomendasikan
PWD $TEST_SRCDIR/workspace-name direkomendasikan
SHLVL 2 direkomendasikan
TEST_INFRASTRUCTURE_FAILURE_FILE jalur absolut ke file pribadi dalam direktori yang dapat ditulis (File ini hanya boleh digunakan untuk melaporkan kegagalan yang berasal dari infrastruktur pengujian, bukan sebagai mekanisme umum untuk melaporkan kegagalan pengujian yang tidak stabil. Dalam konteks ini, infrastruktur pengujian didefinisikan sebagai sistem atau library yang tidak bersifat khusus untuk pengujian, tetapi dapat menyebabkan kegagalan pengujian dengan kegagalan fungsi. Baris pertama adalah nama komponen infrastruktur pengujian yang menyebabkan kegagalan, sedangkan baris kedua adalah deskripsi kegagalan yang dapat dibaca manusia. Baris tambahan akan diabaikan). opsional
TEST_LOGSPLITTER_OUTPUT_FILE jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk menulis log protobuffer LogSplitter) opsional
TEST_PREMATURE_EXIT_FILE jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk merekam panggilan ke exit()) opsional
TEST_RANDOM_SEED Jika opsi --runs_per_test digunakan, TEST_RANDOM_SEED akan ditetapkan ke run number (dimulai dengan 1) untuk setiap pengujian individu. opsional
TEST_RUN_NUMBER Jika opsi --runs_per_test digunakan, TEST_RUN_NUMBER akan ditetapkan ke run number (dimulai dengan 1) untuk setiap pengujian individu. opsional
TEST_TARGET Nama target yang sedang diuji opsional
TEST_SIZE Pengujian size opsional
TEST_TIMEOUT Menguji timeout dalam hitungan detik opsional
TEST_SHARD_INDEX indeks shard, jika sharding digunakan opsional
TEST_SHARD_STATUS_FILE jalur ke file untuk menyentuh guna menunjukkan dukungan untuk sharding opsional
TEST_SRCDIR jalur absolut ke dasar hierarki runfiles wajib
TEST_TOTAL_SHARDS total shard count, jika sharding digunakan opsional
TEST_TMPDIR jalur mutlak ke direktori pribadi yang dapat ditulis wajib
TEST_WORKSPACE nama ruang kerja repositori lokal opsional
TEST_UNDECLARED_OUTPUTS_DIR jalur absolut ke direktori yang dapat ditulis pribadi (digunakan untuk menulis output pengujian yang tidak dideklarasikan). File apa pun yang ditulis ke direktori TEST_UNDECLARED_OUTPUTS_DIR akan di-zip dan ditambahkan ke file outputs.zip di bagian bazel-testlogs. opsional
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis anotasi .part output anotasi yang tidak dideklarasikan dan file .pb). opsional
TEST_WARNINGS_OUTPUT_FILE jalur absolut ke file pribadi dalam direktori yang dapat ditulis (digunakan untuk menulis peringatan target pengujian) opsional
TESTBRIDGE_TEST_ONLY nilai --test_filter, jika ditentukan opsional
TZ UTC wajib
USER nilai getpwuid(getuid())->pw_name wajib
XML_OUTPUT_FILE Lokasi tempat tindakan pengujian harus menulis file output XML hasil pengujian. Jika tidak, Bazel akan menghasilkan file output XML default yang menggabungkan log pengujian sebagai bagian dari tindakan pengujian. Skema XML didasarkan pada skema hasil pengujian JUnit. opsional
BAZEL_TEST Menunjukkan bahwa file yang dapat dieksekusi dijalankan oleh bazel test wajib

Lingkungan mungkin berisi entri tambahan. Pengujian tidak boleh bergantung pada keberadaan, ketidakhadiran, atau nilai variabel lingkungan yang tidak tercantum di atas.

Direktori kerja awal harus $TEST_SRCDIR/$TEST_WORKSPACE.

Id proses, id grup proses, id sesi, dan id proses induk saat ini tidak ditentukan. Proses ini mungkin atau mungkin bukan pemimpin grup proses atau pemimpin sesi. Proses ini mungkin memiliki atau tidak memiliki terminal pengontrol. Proses tersebut mungkin tidak memiliki proses turunan yang sedang berjalan atau belum dijalankan. Proses ini tidak boleh memiliki beberapa thread saat kode pengujian mendapatkan kontrol.

Deskriptor file 0 (stdin) akan terbuka untuk dibaca, tetapi item yang dilampirkan tidak ditentukan. Pengujian tidak boleh membacanya. Deskripsi file 1 (stdout) dan 2 (stderr) harus terbuka untuk penulisan, tetapi item yang dilampirkan tidak ditentukan. Dapat berupa terminal, pipa, file reguler, atau apa pun yang dapat ditulis karakternya. Mereka dapat berbagi entri dalam tabel file terbuka (yang berarti mereka tidak dapat mencari secara independen). Pengujian tidak boleh mewarisi deskripsi file lain yang terbuka.

Umask awal adalah 022 atau 027.

Tidak ada alarm atau timer interval yang harus ditunda.

Mask awal dari sinyal yang diblokir akan kosong. Semua sinyal harus ditetapkan ke tindakan defaultnya.

Batas resource awal, baik virtual maupun hard, harus ditetapkan sebagai berikut:

Referensi Batas
RLIMIT_AS tak terbatas
RLIMIT_CORE belum ditetapkan
RLIMIT_CPU tak terbatas
RLIMIT_DATA tak terbatas
RLIMIT_FSIZE tak terbatas
RLIMIT_LOCKS tak terbatas
RLIMIT_MEMLOCK tak terbatas
RLIMIT_MSGQUEUE belum ditetapkan
RLIMIT_NICE belum ditetapkan
RLIMIT_NOFILE minimal 1024
RLIMIT_NPROC belum ditetapkan
RLIMIT_RSS tak terbatas
RLIMIT_RTPRIO belum ditetapkan
RLIMIT_SIGPENDING belum ditetapkan
RLIMIT_STACK tidak terbatas, atau 2044 KB <= rlim <= 8192 KB

Waktu proses awal (seperti yang ditampilkan oleh times()) dan pemakaian resource (seperti yang ditampilkan oleh getrusage()) tidak ditentukan.

Kebijakan penjadwalan dan prioritas awal belum ditentukan.

Peran sistem host

Selain aspek konteks pengguna di bawah kontrol langsung runner pengujian, sistem operasi tempat pengujian dijalankan harus memenuhi properti tertentu agar pengujian yang dijalankan dapat dianggap valid.

Filesystem

Direktori utama yang diamati oleh pengujian mungkin merupakan direktori utama yang sebenarnya.

/proc harus dipasang.

Semua alat build harus ada di jalur absolut pada /usr yang digunakan oleh penginstalan lokal.

Jalur yang dimulai dengan /home mungkin tidak tersedia. Pengujian tidak boleh mengakses jalur tersebut.

/tmp dapat ditulis, tetapi pengujian harus menghindari penggunaan jalur ini.

Pengujian tidak boleh menganggap bahwa jalur konstan apa pun tersedia untuk penggunaan eksklusifnya.

Pengujian tidak boleh mengasumsikan bahwa waktu diaktifkan untuk semua sistem file yang terpasang.

Pengguna dan grup

Akar pengguna, tidak seorang pun, dan pengujian unit harus ada. Root grup, tak seorang pun, dan harus ada.

Pengujian harus dijalankan sebagai pengguna non-root. ID pengguna yang sebenarnya dan efektif harus sama; begitu juga untuk ID grup. Selain itu, ID pengguna, ID grup, nama pengguna, dan nama grup saat ini tidak ditentukan. Kumpulan ID grup tambahan tidak ditentukan.

ID pengguna dan ID grup saat ini harus memiliki nama yang sesuai yang dapat diambil dengan getpwuid() dan getgrgid(). Hal ini juga mungkin tidak berlaku untuk ID grup tambahan.

Pengguna saat ini harus memiliki direktori utama. Dokumen tersebut mungkin tidak dapat ditulis. Pengujian tidak boleh mencoba menulis ke sana.

Jaringan

Nama host tidak ditentukan. Kode mungkin berisi atau tidak berisi titik. Menyelesaikan nama host harus memberikan alamat IP host saat ini. Menyelesaikan potongan nama host setelah titik pertama juga harus berfungsi. Nama host localhost harus ditetapkan.

Referensi lainnya

Pengujian diberikan setidaknya satu core CPU. Yang lain mungkin tersedia, tetapi ini tidak dijamin. Aspek performa lainnya dari inti ini tidak ditetapkan. Anda dapat meningkatkan reservasi ke jumlah inti CPU yang lebih tinggi dengan menambahkan tag "cpu:n" (dengan n adalah angka positif) ke aturan pengujian. Jika mesin memiliki total CPU lebih sedikit dari yang diminta, Bazel akan tetap menjalankan pengujian. Jika pengujian menggunakan sharding, setiap individual shard akan mencadangkan jumlah inti CPU yang ditentukan di sini.

Pengujian dapat membuat subproses, tetapi tidak dapat memproses grup atau sesi.

Ada batasan jumlah file input yang dapat digunakan oleh pengujian. Batas ini dapat berubah, tetapi saat ini berada dalam rentang puluhan ribu input.

Waktu dan tanggal

Waktu dan tanggal saat ini tidak ditentukan. Zona waktu sistem tidak ditentukan.

X Windows mungkin tersedia atau tidak. Pengujian yang memerlukan server X harus dimulai di Xvfb.

Menguji interaksi dengan sistem file

Semua jalur file yang ditentukan dalam variabel lingkungan pengujian mengarah ke suatu tempat pada sistem file lokal, kecuali ditentukan lain.

Pengujian hanya boleh membuat file dalam direktori yang ditentukan oleh $TEST_TMPDIR dan $TEST_UNDECLARED_OUTPUTS_DIR (jika ditetapkan).

Direktori ini awalnya akan kosong.

Pengujian tidak boleh berupaya menghapus, melakukan chmod, atau mengubah direktori ini.

Direktori ini mungkin berupa link simbolis.

Jenis sistem file $TEST_TMPDIR/. tetap tidak ditentukan.

Pengujian juga dapat menulis file .part ke $TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR untuk menganotasi file output yang tidak dideklarasikan.

Dalam kasus yang jarang terjadi, pengujian mungkin dipaksa untuk membuat file dalam /tmp. Misalnya, batas panjang jalur untuk soket domain Unix biasanya memerlukan pembuatan soket di bagian /tmp. Bazel tidak akan dapat melacak file tersebut; pengujian itu sendiri harus berhati-hati, menggunakan jalur unik untuk menghindari benturan dengan pengujian lain dan menjalankan pengujian dan proses non-pengujian secara bersamaan, dan untuk membersihkan file yang dibuatnya di /tmp.

Beberapa framework pengujian populer, seperti JUnit4 TemporaryFolder atau Go TempDir, memiliki caranya sendiri untuk membuat direktori sementara pada /tmp. Framework pengujian ini mencakup fungsi yang membersihkan file dalam /tmp, sehingga Anda dapat menggunakannya meskipun membuat file di luar TEST_TMPDIR.

Pengujian harus mengakses input melalui mekanisme runfiles, atau bagian lain dari lingkungan eksekusi yang secara khusus dimaksudkan untuk menyediakan file input.

Pengujian tidak boleh mengakses output lain dari sistem build pada jalur yang diambil dari lokasi file yang dapat dieksekusi sendiri.

Tidak ditentukan apakah hierarki runfile berisi file biasa, link simbolis, atau campuran. Hierarki filefile mungkin berisi symlink ke direktori. Pengujian harus menghindari penggunaan jalur yang berisi komponen .. dalam hierarki runfile.

Tidak ada direktori, file, atau symlink dalam hierarki runfiles (termasuk jalur yang melintasi symlink) yang dapat ditulisi. (Oleh karena itu, direktori kerja awal tidak boleh dapat ditulis.) Pengujian tidak boleh berasumsi bahwa ada bagian dari runfile yang dapat ditulis, atau dimiliki oleh pengguna saat ini (misalnya, chmod dan chgrp mungkin gagal).

Hierarki runfile (termasuk jalur yang melintasi symlink) tidak boleh berubah selama eksekusi pengujian. Direktori induk dan pemasangan sistem file tidak boleh berubah dengan cara apa pun yang memengaruhi hasil penyelesaian jalur dalam hierarki runfiles.

Untuk mengambil akses keluar awal, pengujian dapat membuat file di jalur yang ditentukan oleh TEST_PREMATURE_EXIT_FILE saat memulai dan menghapusnya saat keluar. Jika Bazel melihat file saat pengujian selesai, akan diasumsikan bahwa pengujian keluar sebelum waktunya dan menandainya sebagai gagal.

Konvensi tag

Beberapa tag dalam aturan pengujian memiliki makna khusus. Lihat juga Bazel Build Encyclopedia di atribut tags.

Tag Arti
exclusive tidak menjalankan pengujian lain secara bersamaan
external pengujian memiliki dependensi eksternal; nonaktifkan pembuatan cache pengujian
large Konvensi test_suite; rangkaian pengujian besar
manual * jangan sertakan target pengujian dalam pola target karakter pengganti seperti :..., :*, atau :all
medium Konvensi test_suite; rangkaian pengujian sedang
small Konvensi test_suite; rangkaian pengujian kecil
smoke Konvensi test_suite; berarti harus dijalankan sebelum melakukan perubahan kode ke dalam sistem kontrol versi

Runfile

Pada contoh berikut, anggap ada aturan *_binary() berlabel //foo/bar:unittest, dengan dependensi runtime pada aturan yang berlabel //deps/server:server.

Lokasi

Direktori runfiles untuk //foo/bar:unittest target adalah direktori $(WORKSPACE)/$(BINDIR)/foo/bar/unittest.runfiles. Jalur ini disebut sebagai runfiles_dir.

Dependensi

Direktori runfiles dideklarasikan sebagai dependensi waktu kompilasi aturan *_binary(). Direktori runfile itu sendiri bergantung pada kumpulan file BUILD yang memengaruhi aturan *_binary() atau dependensi waktu kompilasi atau runtime apa pun. Mengubah file sumber tidak memengaruhi struktur direktori runfile, sehingga tidak memicu pembuatan ulang apa pun.

Daftar Isi

Direktori runfile berisi hal berikut:

  • Symlink ke dependensi runtime: setiap OutputFile dan CommandRule yang merupakan dependensi runtime dari aturan *_binary() direpresentasikan oleh satu symlink dalam direktori runfiles. Nama symlink adalah $(WORKSPACE)/package_name/rule_name. Misalnya, symlink untuk server akan diberi nama $(WORKSPACE)/deps/server/server, dan jalur lengkapnya adalah $(WORKSPACE)/foo/bar/unittest.runfiles/$(WORKSPACE)/deps/server/server. Tujuan symlink adalah OutputFileName() dari OutputFile atau CommandRule, yang dinyatakan sebagai jalur absolut. Dengan demikian, tujuan symlink mungkin adalah $(WORKSPACE)/linux-dbg/deps/server/42/server.
  • Symlink ke sub-runfile: untuk setiap *_binary() Z yang merupakan dependensi run-time dari *_binary() C, ada link kedua di direktori run file C ke runfile Z. Nama symlink adalah $(WORKSPACE)/package_name/rule_name.runfiles. Target symlink adalah direktori runfile. Misalnya, semua subprogram memiliki direktori runfile yang sama.