Ensiklopedia uji

Laporkan masalah Lihat sumber Per Malam · 7,4 kami. 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Spesifikasi lengkap lingkungan eksekusi pengujian.

Latar belakang

Bahasa BUILD Bazel 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, sehingga pemanggilan semacam itu tidak akan mematuhi mandat yang dijelaskan di bawah.

Pengujian harus hermetis: yaitu, pengujian hanya boleh mengakses resource yang memiliki dependensi yang dideklarasikan. Jika pengujian tidak tertutup dengan benar maka mereka tidak memberikan hasil yang dapat direproduksi secara historis. Hal ini dapat berupa signifikan untuk penemuan penyebab (menentukan perubahan mana yang merusak tes), kemampuan audit teknis rilis, dan isolasi resource pengujian (otomatis tidak boleh melakukan DDOS server karena beberapa tes kebetulan berkomunikasi dengan itu).

Tujuan

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

Spesifikasi lingkungan pengujian membantu penulis pengujian agar tidak mengandalkan perilaku yang tidak ditentukan, sehingga memberi infrastruktur pengujian lebih banyak kebebasan untuk melakukan perubahan implementasi. Spesifikasi ini memperketat beberapa celah yang saat ini memungkinkan banyak pengujian lulus meskipun tidak hermetis, deterministik, dan dapat masuk kembali dengan benar.

Halaman ini dimaksudkan untuk bersifat normatif dan otoritatif. Jika spesifikasi ini dan perilaku runner pengujian yang diterapkan tidak sesuai, spesifikasi akan diprioritaskan.

Spesifikasi yang Diusulkan

Kata kunci "HARUS", "TIDAK BOLEH", "WAJIB", "HARUS", "TIDAK BOLEH", "HARUS", "TIDAK BOLEH", "DISARANKAN", "MUNGKIN", dan "OPSIONAL" 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 hal lain yang disimpan dalam kontrol versi.) Satu pengguna menulis untuk menyatakan invarian yang diharapkan akan dipertahankan. Pengguna lain jalankan pengujian nanti untuk memeriksa apakah invarian telah rusak. Jika pengujian bergantung pada variabel selain file sumber (non-hermetis), nilainya akan berkurang, karena pengguna berikutnya tidak dapat memastikan perubahan mereka yang salah saat pengujian berhenti lulus.

Oleh karena itu, hasil pengujian hanya boleh bergantung pada:

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

Saat ini, perilaku tersebut tidak diterapkan. Namun, runner pengujian berhak menambahkan penegakan tersebut di masa mendatang.

Peran sistem build

Aturan pengujian analog dengan aturan biner karena setiap aturan harus menghasilkan program yang dapat dieksekusi. Untuk beberapa bahasa, ini adalah program stub yang menggabungkan harness khusus bahasa dengan kode pengujian. Aturan pengujian harus menghasilkan output juga. Selain pengujian utama yang dapat dieksekusi, runner pengujian akan memerlukan manifes runfiles, file input yang harus disediakan ke pengujian saat runtime, dan mungkin memerlukan informasi tentang jenis, ukuran, dan tag suatu 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 berbagi 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 runner pengujian, bukan referensi hardcode ke lokasi absolut dalam hierarki sumber atau output.

Peran runner pengujian

Dari sudut pandang {i>test runner<i}, setiap tes 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 mandiri harus dianggap kredibel. Jika proses pengujian berjalan sampai selesai dan berakhir secara normal dengan {i>exit code<i} nol, berarti pengujian telah lulus. Hasil lainnya dianggap sebagai kegagalan pengujian. Secara khusus, menulis string PASS atau FAIL ke stdout tidak memiliki signifikansi bagi runner pengujian.

Jika pengujian membutuhkan waktu terlalu lama untuk dijalankan, melebihi batas resource, atau pengujian jika tidak mendeteksi perilaku yang dilarang, {i>runner<i} dapat memilih untuk mematikan pengujian dan memperlakukan proses sebagai kegagalan. Runner tidak boleh melaporkan pengujian sebagai lulus setelah mengirim sinyal ke proses pengujian atau turunannya.

Seluruh target pengujian (bukan metode atau pengujian individual) diberi waktu terbatas untuk dijalankan hingga selesai. Batas waktu untuk pengujian didasarkan pada atribut timeout-nya sesuai dengan tabel berikut:

timeout Batas Waktu (dtk.)
short 60
sedang 300
long 900
abadi 3600

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

ukuran Label waktu tunggu tersirat
small short
sedang sedang
large long
sangat besar abadi

Gambar "besar" pengujian tanpa setelan waktu tunggu eksplisit akan dialokasikan 900 detik untuk berlari. Pengujian "sedang" dengan waktu tunggu "singkat" akan diberi waktu 60 detik.

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

Semua kombinasi label size dan timeout sah, sehingga pengujian "besar" dapat dideklarasikan memiliki waktu tunggu "singkat". Kemungkinan besar, hal ini akan melakukan beberapa hal yang sangat mengerikan dengan sangat cepat.

Pengujian dapat ditampilkan dengan cepat secara arbitrer, terlepas dari waktu tunggu. Tes tidak diberi sanksi untuk waktu tunggu yang terlalu banyak, meskipun peringatan mungkin dikeluarkan: Anda harus umumnya menyetel waktu tunggu seketat mungkin tanpa menimbulkan kegagalan.

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)
short 0
sedang 30
long 300
abadi 900

Misalnya, jika skor "menengah" pengujian selesai dalam 5,5 detik, pertimbangkan untuk menyetel timeout = "short" atau size = "small". Menggunakan bazel --test_verbose_timeout_warnings akan menampilkan pengujian yang ukuran yang ditetapkan 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, runner pengujian harus menganggap proses berjalan selesai dan menghitungnya sebagai berhasil atau gagal berdasarkan kode keluar yang diamati dari proses utama. Runner pengujian dapat menghentikan proses yang menyimpang. 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. Saat sharding diaktifkan, runner pengujian diluncurkan satu kali per bagian. Variabel lingkungan TEST_TOTAL_SHARDS adalah jumlah shard, dan TEST_SHARD_INDEX adalah indeks sharding, dimulai dari 0. Pelari menggunakan informasi ini untuk memilih pengujian yang dapat dijalankan - misalnya, menggunakan strategi round-robin. Tidak semua runner pengujian mendukung sharding. Jika mendukung sharding, runner harus membuat atau memperbarui tanggal terakhir diubah file yang ditentukan oleh TEST_SHARD_STATUS_FILE. Jika tidak, jika --incompatible_check_sharding_support diaktifkan, Bazel akan gagal dalam pengujian jika di-shard.

Kondisi awal

Saat menjalankan pengujian, runner pengujian harus menetapkan kondisi tertentu.

Runner pengujian harus memanggil setiap pengujian dengan jalur ke pengujian 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 lulus argumen lain untuk pengujian kecuali pengguna secara eksplisit memintanya.

Blok lingkungan awal harus disusun sebagai berikut:

Variabel Nilai Status
HOME nilai $TEST_TMPDIR disarankan
LANG tidak ditetapkan wajib diisi
LANGUAGE tidak ditetapkan wajib diisi
LC_ALL tidak ditetapkan wajib diisi
LC_COLLATE tidak ditetapkan wajib diisi
LC_CTYPE tidak ditetapkan wajib diisi
LC_MESSAGES tidak ditetapkan wajib diisi
LC_MONETARY tidak ditetapkan wajib diisi
LC_NUMERIC tidak ditetapkan wajib diisi
LC_TIME tidak ditetapkan wajib diisi
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 diisi
PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:. direkomendasikan
PWD $TEST_SRCDIR/workspace-name direkomendasikan
SHLVL 2 disarankan
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 khusus pengujian, tetapi dapat menyebabkan kegagalan pengujian karena tidak berfungsi. Baris pertama adalah nama komponen infrastruktur pengujian yang menyebabkan kegagalan, baris kedua adalah deskripsi kegagalan yang dapat dibaca manusia. Baris tambahan akan diabaikan.) opsional
TEST_LOGSPLITTER_OUTPUT_FILE jalur absolut ke file pribadi di 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 menangkap panggilan ke exit()) opsional
TEST_RANDOM_SEED Jika opsi --runs_per_test digunakan, TEST_RANDOM_SEED disetel ke run number (dimulai dengan 1) untuk setiap pengujian. opsional
TEST_RUN_NUMBER Jika opsi --runs_per_test digunakan, TEST_RUN_NUMBER ditetapkan ke run number (dimulai dengan 1) untuk setiap pengujian yang dijalankan. opsional
TEST_TARGET Nama target yang sedang diuji opsional
TEST_SIZE Pengujian size opsional
TEST_TIMEOUT Pengujian timeout dalam hitungan detik opsional
TEST_SHARD_INDEX indeks shard, jika sharding digunakan opsional
TEST_SHARD_STATUS_FILE jalur ke file yang akan disentuh untuk menunjukkan dukungan untuk sharding opsional
TEST_SRCDIR jalur absolut ke dasar hierarki runfiles wajib diisi
TEST_TOTAL_SHARDS total shard count, jika sharding digunakan opsional
TEST_TMPDIR jalur absolut ke direktori pribadi yang dapat ditulis wajib diisi
TEST_WORKSPACE nama ruang kerja repositori lokal opsional
TEST_UNDECLARED_OUTPUTS_DIR jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis perintah output pengujian). Setiap file yang ditulis ke direktori TEST_UNDECLARED_OUTPUTS_DIR akan dikompresi dan ditambahkan ke file outputs.zip di bazel-testlogs. opsional
TEST_UNDECLARED_OUTPUTS_ANNOTATIONS_DIR jalur absolut ke direktori pribadi yang dapat ditulis (digunakan untuk menulis file .part dan .pb anotasi output pengujian yang tidak dideklarasikan). opsional
TEST_WARNINGS_OUTPUT_FILE jalur absolut ke file pribadi di direktori yang dapat ditulis (digunakan untuk menulis peringatan target pengujian) opsional
TESTBRIDGE_TEST_ONLY nilai --test_filter, jika ditentukan opsional
TZ UTC wajib diisi
USER nilai getpwuid(getuid())->pw_name wajib diisi
XML_OUTPUT_FILE Lokasi tempat tindakan pengujian harus menulis file output XML hasil pengujian. Jika tidak, Bazel akan membuat 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 pengujian yang dapat dieksekusi didorong oleh bazel test wajib diisi

Lingkungan dapat berisi entri tambahan. Pengujian tidak boleh bergantung pada kehadiran, ketidakhadiran, atau nilai dari variabel lingkungan apa pun yang tidak tercantum di atas.

Direktori kerja awal harus $TEST_SRCDIR/$TEST_WORKSPACE.

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

Deskriptor file 0 (stdin) harus terbuka untuk dibaca, tetapi apa yang dilampirkan tidak ditentukan. Pengujian tidak boleh membacanya. Deskriptor file 1 (stdout) dan 2 (stderr) akan terbuka untuk penulisan, tetapi apa yang dilampirkan pada belum ditetapkan. Itu bisa berupa terminal, pipa, file biasa, atau apa pun yang karakter mana yang dapat ditulis. Keduanya dapat berbagi entri dalam tabel file terbuka (yang berarti keduanya tidak dapat mencari secara independen). Pengujian tidak boleh mewarisi deskripsi file terbuka lainnya.

Umask awal harus 022 atau 027.

Tidak ada alarm atau timer interval yang tertunda.

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

Batas resource awal, baik lembut maupun keras, harus disetel sebagai berikut:

Resource 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 setidaknya 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 penggunaan resource (seperti yang ditampilkan oleh getrusage()) tidak ditentukan.

Kebijakan penjadwalan awal dan prioritas tidak ditentukan.

Peran sistem host

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

Filesystem

Direktori utama yang diamati oleh pengujian mungkin atau mungkin bukan direktori utama yang sebenarnya.

/proc akan dipasang.

Semua alat build akan 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 harus dapat ditulis, tetapi pengujian harus menghindari penggunaan jalur ini.

Pengujian tidak boleh berasumsi bahwa setiap jalur konstan tersedia untuk gunakan.

Pengujian tidak boleh mengasumsikan bahwa atime diaktifkan untuk sistem file yang dipasang.

Pengguna dan grup

Pengguna root, nobody, dan unittest harus ada. Grup {i>root<i}, {i>nobody<i}, dan eng harus ada.

Pengujian harus dijalankan sebagai pengguna non-root. ID pengguna yang sebenarnya dan efektif harus sama; juga untuk ID grup. Di luar ini, id pengguna saat ini, id grup, nama pengguna, dan nama grup tidak ditentukan. Kumpulan ID grup tambahan belum ditetapkan.

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

Pengguna saat ini harus memiliki direktori {i>home<i}. Dokumen ini mungkin tidak dapat ditulis. Pengujian tidak boleh mencoba menulis ke file tersebut.

Networking

Nama host tidak ditentukan. Nama ini mungkin berisi titik atau tidak. Me-resolve nama host harus memberikan alamat IP host saat ini. Me-resolve pemotongan nama host setelah titik pertama juga harus berfungsi. Nama host localhost harus di-resolve.

Referensi lainnya

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

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

Ada batasan jumlah file input yang dapat digunakan 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 memulai Xvfb.

Menguji interaksi dengan sistem file

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

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

Direktori ini awalnya akan kosong.

Pengujian tidak boleh mencoba menghapus, 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 di /tmp. Misalnya, batas panjang jalur untuk soket domain Unix biasanya memerlukan pembuatan soket di /tmp. Bazel tidak akan dapat melacak file tersebut; pengujian itu sendiri harus memastikan kerahasiaannya, menggunakan jalur unik untuk menghindari tabrakan dengan pengujian dan proses non-pengujian lainnya yang berjalan secara bersamaan, serta untuk membersihkan file yang dibuatnya di /tmp.

Beberapa framework pengujian populer, seperti JUnit4 TemporaryFolder atau Go TempDir, miliki cara mereka sendiri untuk membuat direktori sementara di /tmp. Pengujian ini framework mencakup fungsi yang membersihkan file di /tmp, sehingga Anda dapat menggunakan file tersebut meskipun mereka membuat file di luar TEST_TMPDIR.

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

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

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

Tidak ada direktori, file, atau symlink dalam hierarki runfile (termasuk jalur yang melintasi symlink) yang boleh ditulis. (Artinya, direktori kerja awal tidak boleh dapat ditulis.) Pengujian tidak boleh mengasumsikan bahwa runfile dapat ditulis, atau dimiliki oleh pengguna saat ini (misalnya chmod dan chgrp dapat gagal).

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

Untuk menangkap exit (keluar) lebih awal, pengujian bisa membuat file di jalur yang ditentukan oleh TEST_PREMATURE_EXIT_FILE saat mulai dan menghapusnya saat keluar. Jika Bazel melihat setelah pengujian selesai, maka akan diasumsikan bahwa pengujian keluar sebelum waktunya dan menandainya sebagai gagal.

Konvensi tag

Beberapa tag dalam aturan pengujian memiliki arti khusus. Lihat juga Bazel Build Encyclopedia pada atribut tags.

Tag Arti
exclusive tidak boleh menjalankan pengujian lain secara bersamaan
external pengujian memiliki dependensi eksternal; nonaktifkan 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; serangkaian pengujian kecil
smoke Konvensi test_suite; berarti harus dijalankan sebelum melakukan perubahan kode ke dalam sistem kontrol versi

Runfiles

Berikut ini, asumsikan ada aturan *_binary() berlabel //foo/bar:unittest, dengan dependensi waktu proses pada aturan 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 dari aturan *_binary(). Direktori runfile itu sendiri bergantung pada kumpulan file BUILD yang memengaruhi aturan *_binary() atau dependensi waktu compile atau waktu prosesnya. Memodifikasi file sumber tidak mempengaruhi struktur {i>runfiles <i}dan tidak memicu pembuatan ulang apa pun.

Daftar Isi

Direktori runfiles berisi hal-hal berikut:

  • Symlink ke dependensi run-time: setiap OutputFile dan CommandRule yang merupakan dependensi run-time dari aturan *_binary() diwakili oleh satu symlink di direktori runfile. Nama symlink-nya $(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 run-time dependensi *_binary() C, ada link kedua di runfiles direktori C ke {i> runfile<i} Z. Nama symlink-nya $(WORKSPACE)/package_name/rule_name.runfiles. Target symlink adalah direktori runfiles. Misalnya, semua subprogram memiliki direktori runfile umum.