Wawancara Rust: Bagaimana Anda merancang kebijakan peringatan Rust 1.97 untuk CI?

Konteks dan cakupan

Rust 1.97 mengekspos build.warnings di Cargo: warn adalah default, allow menyembunyikan lint yang dapat disesuaikan, dan deny membuat peringatan lint dari paket lokal menggagalkan proses build. Perilaku ini juga dapat diubah dengan CARGO_BUILD_WARNINGS atau --keep-going. Rilis ini juga membuat stderr linker yang berhasil menjadi terlihat secara default dan memperkenalkan lint khusus linker_messages.

Ini ditujukan bagi engineer yang memelihara workspace Rust, toolchain compiler, atau pipeline rilis. Asumsikan terdapat beberapa crate lokal, dependensi pihak ketiga, build Linux dan Windows, serta satu target yang dikompilasi silang (cross-compiled). Tujuannya bukan untuk mengubah setiap baris kuning menjadi merah; setiap sinyal memerlukan pemilik (owner), gerbang kegagalan (failure gate), dan jalur penyelesaian.

Apa yang dinilai oleh pewawancara

• Bisakah Anda memisahkan lint kode lokal, output dependensi, diagnostik linker, dan kesalahan kompilasi?
• Bisakah Anda menjelaskan batasan dari warn, allow, dan deny alih-alih memperlakukan RUSTFLAGS=-Dwarnings sebagai satu-satunya solusi?
• Bisakah Anda menyeimbangkan umpan balik lokal yang cepat, penegakan CI, dan reproduktibilitas di berbagai target?
• Bisakah Anda menjaga agar pengecualian tetap dapat diaudit dan menjelaskan dampaknya terhadap cache, skrip build, dan pembaruan toolchain?

Jawaban yang lemah adalah mengatakan "gunakan -D warnings di CI." Jawaban yang kuat mengklasifikasikan sinyal terlebih dahulu, memilih kebijakan tingkat Cargo, dan mengontrol positif palsu dengan baseline, pemilik, dan perintah verifikasi.

Pertanyaan untuk diklarifikasi terlebih dahulu

1. Apakah gerbang tersebut hanya mencakup crate workspace, atau juga dependensi dan output linker? build.warnings milik Cargo terutama berlaku untuk paket lokal; peringatan dependensi memerlukan pengamatan terpisah.
2. Apakah CI membangun beberapa target? Kompilasi silang memerlukan catatan terpisah untuk linker, sysroot, SDK, dan diagnostik khusus target.
3. Haruskah satu eksekusi mengumpulkan setiap masalah? Jika ya, --keep-going membantu mengumpulkan peringatan dan kesalahan terkait, tetapi tidak membuat build yang gagal menjadi berhasil.
4. Apakah pengecualian sementara diizinkan? Catat lint atau pesan, target, alasan, pemilik, dan tanggal peninjauan, atau allow akan menjadi pembungkaman permanen.

Jawaban 30 detik

"Saya akan mengklasifikasikan output ke dalam lint lokal yang dapat disesuaikan, peringatan dependensi pihak ketiga, diagnostik linker, dan kesalahan kompilasi. Pengembangan lokal tetap pada warn untuk umpan balik yang cepat; CI menggunakan deny untuk crate workspace dan --keep-going untuk mengumpulkan hasil lengkap. Dependensi tetap terlihat dan dilacak untuk pembaruan alih-alih memblokir setiap perubahan hanya karena upstream memiliki peringatan. Output linker mendapatkan baseline per target, dan hanya pesan yang diverifikasi tidak berbahaya yang diizinkan secara eksplisit. Setiap pengecualian memiliki pemilik dan tanggal kedaluwarsa. Saya akan memvalidasi kebijakan ini dengan build multi-target, pengukuran cache hit, serta simulasi pembaruan toolchain dan dependensi."

Solusi langkah demi langkah

1. Tentukan batas-batas sinyal

Pisahkan kode keluar (exit codes), stderr, dan tingkat lint. Kesalahan kompilasi selalu memblokir. build.warnings mengontrol lint yang dapat disesuaikan dalam paket lokal. Output dependensi tetap berada di log verbose sehingga pemeliharaan upstream tidak dibebankan secara diam-diam ke repositori ini. Diagnostik linker dicatat berdasarkan toolchain dan target.

2. Buat lapisan lingkungan

Pertahankan pengembangan lokal pada warn: developer dapat melihat masalah tanpa terhenti oleh seluruh backlog warisan. Gunakan deny untuk paket repositori itu sendiri di CI sehingga kode baru tidak dapat menambahkan lint yang dapat disesuaikan. Pipeline rilis juga mengunci versi toolchain, lockfile, dan matriks target sehingga 'berfungsi di mesin saya' bukan merupakan kriteria rilis.

[build]
warnings = "warn"

[lints.rust]
linker_messages = "allow"

Baris linker_messages = "allow" hanya valid setelah pesan platform tersebut terbukti tidak berbahaya; ini bukan wildcard untuk semua stderr linker. CI dapat mengubah tingkat peringatan paket lokal dengan variabel lingkungan:

CARGO_BUILD_WARNINGS=deny cargo check --workspace --all-targets --keep-going

3. Tangani dependensi dan cache

Tempatkan peringatan dependensi di papan pembaruan atau allowlist bersama crate, versi, target, dan build tempat pertama kali terlihat. Jangan menyembunyikan risiko upstream secara global. Catatan rilis Rust 1.97 menyatakan bahwa mengubah perilaku peringatan tidak membatalkan build cache yang mendasarinya. Tetap pantau tingkat cache hit karena mengubah target, toolchain, atau rustflags dapat membuat kunci cache yang berbeda.

4. Buat kompilasi silang dapat dijelaskan

Untuk setiap target, simpan versi compiler, jalur linker, sysroot, SDK, output skrip build, dan baseline peringatan. Jika suatu platform memerlukan pengecualian linker sementara, batasi pada target tersebut dan periksa kembali saat linker berubah. "Linux tidak menghasilkan peringatan" bukan bukti bahwa Windows aman.

5. Rancang pengecualian dan jalur keluar

Pengecualian mencatat empat bidang: lint atau pesan yang tepat, target, pemilik, dan tanggal kedaluwarsa. Hasilkan kembali laporan peringatan untuk setiap pembaruan toolchain dan release candidate. Jika jumlah atau pengulangan pengecualian meningkat, jeda perluasan matriks build dan selesaikan penyebabnya terlebih dahulu.

6. Verifikasi bahwa kebijakan berfungsi

Gunakan branch sementara yang sengaja memicu lint lokal untuk memverifikasi perbedaan antara warn dan deny; gunakan sampel linker lintas platform untuk memverifikasi baseline; dan jalankan simulasi pembaruan dependensi untuk memastikan peringatan upstream tetap terlihat. Lacak penyebab kegagalan per target, jumlah peringatan, waktu build, tingkat cache hit, dan usia pengecualian. Keberhasilan berarti lint lokal baru memblokir CI, masalah dependensi tidak disembunyikan, dan pesan linker yang disetujui tetap dapat dilacak.

Contoh jawaban berkualitas tinggi

"Saya tidak akan memulai dengan -Dwarnings global. Pertama, saya akan menentukan apakah gerbang tersebut melindungi dari regresi workspace atau setiap pesan perkakas. build.warnings milik Rust 1.97 adalah batasan yang baik untuk crate lokal: pertahankan pengembangan pada warn, lalu gunakan CARGO_BUILD_WARNINGS=deny dengan cargo check --workspace --all-targets --keep-going di CI untuk mengumpulkan lebih banyak hasil dalam satu proses. Peringatan dependensi masuk ke antrean pembaruan; mereka harus tetap terlihat dan memiliki versi, tetapi peringatan upstream seharusnya tidak secara otomatis memblokir kode aplikasi.

Saya akan mempertahankan baseline linker per target. Hanya setelah mengonfirmasi bahwa pesan tersebut tidak berbahaya, saya akan mengizinkan linker_messages dalam konfigurasi target tersebut, dengan platform, toolchain, alasan, pemilik, dan tanggal peninjauan yang dicatat. Target kompilasi silang menyimpan catatan linker dan sysroot secara terpisah. Sebelum rilis, saya akan menggunakan lint yang disengaja, satu pembaruan dependensi, dan satu pembaruan toolchain untuk memverifikasi kode keluar, log lengkap, perilaku cache, dan kedaluwarsa pengecualian. Kebijakan ini kemudian memblokir regresi baru yang dapat dipertanggungjawabkan tanpa menyembunyikan output yang tidak dikenal."

Kesalahan umum

• Kesalahan: Menyetel RUSTFLAGS=-Dwarnings secara global. → Mengapa gagal: Ini mencampurkan batasan compiler, skrip build, dan dependensi, sehingga pembaruan dapat mengubah output yang tidak terkait menjadi kegagalan yang tidak dapat dijelaskan. → Perbaikan: Gunakan kebijakan peringatan paket lokal Cargo dan lacak dependensi serta linker secara terpisah.
• Kesalahan: Menggunakan allow untuk menghilangkan setiap garis merah. → Mengapa gagal: Lint yang dapat disesuaikan, kesalahan kompilasi, dan stderr linker non-lint adalah sinyal yang berbeda. → Perbaikan: Izinkan hanya lint atau pesan yang telah diverifikasi dan simpan log mentah.
• Kesalahan: Memperlakukan --keep-going sebagai keberhasilan. → Mengapa gagal: Ini hanya mengumpulkan hasil; ini tidak mengubah kesalahan menjadi build yang berhasil. → Perbaikan: Periksa kode keluar akhir dan klasifikasikan laporan berdasarkan crate dan target.
• Kesalahan: Hanya memvalidasi target default. → Mengapa gagal: Linker, SDK, dan skrip build bervariasi berdasarkan platform. → Perbaikan: Buat baseline independen dan simulasi pembaruan untuk setiap target rilis.

Pertanyaan lanjutan dan tanggapan

Bagaimana jika sebuah crate dependensi membanjiri log rilis dengan peringatan?

Agregasikan berdasarkan crate, versi, dan target alih-alih membungkamnya. Jika peringatan telah diperbaiki di upstream, jadwalkan pembaruan yang dapat dibatalkan (reversible). Jika pembaruan harus menunggu, catat rentang versi dan penanggung jawab risiko, serta pisahkan lint repositori dari pengamatan dependensi. Blokir hanya jika dependensi tersebut melanggar gerbang keamanan rilis yang telah ditetapkan.

Mengapa tidak menangani semuanya dengan RUSTFLAGS=-Dwarnings?

Rustflags global memengaruhi skrip build, procedural macro, dan pemilihan target, membuat batasannya lebih sulit dijelaskan serta berpotensi mengubah perilaku lintas platform dan kunci cache. build.warnings milik Cargo menetapkan aturan yang lebih spesifik: CI memblokir lint yang dapat disesuaikan dari paket lokal, sementara output lainnya mengikuti jalur auditnya sendiri.

Peringatan linker suatu target berubah pada setiap build. Apa yang Anda lakukan?

Pertama, kunci toolchain, linker, SDK, dan lingkungan build, lalu bandingkan stderr mentah. Jika pesannya stabil dan tidak berbahaya, izinkan untuk target tersebut dengan tanggal peninjauan. Jika teksnya berubah atau muncul bersamaan dengan kegagalan link, hapus pengecualian dan perbaiki toolchain atau konfigurasi build.