siftwise v0.3, risk temelli test sıralaması ve CI için zaman bütçesi ekliyor

Açık kaynak ve self-hosted bir araç olan siftwise, CI test çalıştırmalarını bir kod değişikliğinin gerçekten etkileyebileceği testlere daraltıyor ve her başarısızlığı yeni, main üzerinde zaten bozuk ya da flaky olarak etiketleyen aracın 0.3.0 sürümü yayımlandı. dev.to'daki duyuruya göre bu sürümün teması daha akıllı seçim: testler artık başarısızlık olasılığına göre sıralanıyor, çalıştırmalar bir zaman bütçesiyle kısıtlanabiliyor ve seçim desteği JavaScript ve Java yapılarına uzanıyor.

Önce en riskli testler

Daha önce siftwise doğru testleri seçiyor ama bunları yol sırasına göre çalıştırıyordu; bu yüzden son testteki bir başarısızlık yine tam bir bekleme anlamına geliyordu. v0.3'te seçilen her test bir puan, bir sıra ve bir gerekçe alıyor ve en riskli olanlar önce çalışıyor.

Puan, makine öğrenmesi içermeyen sabit ve belgelenmiş bir formülle hesaplanıyor: değişiklik teste doğrudan ulaşırsa 6, diğer dosyalar üzerinden ulaşırsa 3, yalnızca geçmişe dayanıyorsa 0 puan olan bir bağlantı terimi; testin son kez başarısız olmasından bu yana geçen her yedi günde yarıya inen bir güncellik çarpanının üç katı; ve başarısızlık oranının iki katı. Güncellik ve oran, flaky testler için iskonto edilirken yeni testlere sabit 2 puan veriliyor. Puan eşitliğinde daha hızlı test öne geçiyor.

Sıralama varsayılan olarak açık ve hangi testlerin çalışacağını asla değiştirmiyor, yalnızca ne zaman çalışacağını belirliyor; CLI, GitHub Action, GitLab ve MCP üzerindeki sıra ayarları eski davranışı geri getiriyor. Sıralamaya ne ölçüde uyulduğu runner'a bağlı: pytest, pytest-xdist gibi bir eklenti bunları yeniden sıralamadıkça verilen argümanları izliyor; Go paketleri birbiri ardına en riskli önce olacak şekilde çalışıyor; Jest dosyaları paralel çalıştırdığı için sıralamayı yalnızca bir ipucu olarak ele alıyor; Maven modülleri ise reactor'ın bağımlılık sırasını izliyor.

Bakımcı, gerçek CI geçmişini her çalıştırma yalnızca önceki verilerle değerlendirilecek şekilde yeniden oynattığında, ilk başarısızlıktan önce geçen çalıştırma payının medyanının RDFLib/rdflib'de (Python, 17 çalıştırma) %37,3'ten %1,4'e, agent-substrate/substrate'te (Go, 19 çalıştırma) %42,0'dan %25,6'ya düştüğünü bildiriyor. Aynı testler farklı bir sırada çalıştığı için recall değişmedi. Tahmini saniye başına riske göre sıralayan maliyet farkındalıklı bir varyant ise her iki depoda da açık biçimde daha iyi olmadığı için yayımlanmadı.

Gönderi bir gerileme hakkında da açık sözlü. Başlangıçta her dile uygulanan yeni bir import derinliği kuralı substrate'i kötüleştirdi — medyan test sayısına göre %23,3'ten %34,4'e çıktı — çünkü Go'nun import bağlantılı paketlerinin %83'ü birinci derinlikteydi ve bir depends kuralının seçtiği uçtan uca suitlerin önüne yükseltildiler. Düzeltme, Go paketlerini derinlik temelli yükseltmenin dışında bırakırken bunu Python, Jest ve Java test dosyaları için koruyor ve substrate'in sayılarını geri getirdi. Bakımcı, rdflib'nin medyanları yerinde saydığı için import derinliğinin kendisinden hiç hızlanma sağlamadığını belirtiyor.

Zaman bütçeleri

Yeni bir bütçe modu, mesela beş dakikaya hangi testlerin sığdığı sorusunu yanıtlıyor. siftwise select --budget 5m — ya da 90s ya da 1h30m — tahmini süreleri bütçeye sığan en riskli testleri çalıştırıyor; GitHub Action (budget-limited ve budget-left-out bayraklarını çıkarıyor), GitLab, MCP ve API'de de karşılıkları var. Mod varsayılan olarak kapalı.

İki uyarı açıkça belirtiliyor. Bütçe, her testin ortalama geçmiş süresinden oluşturulan bir tahmin, katı bir üst sınır değil; bu yüzden gerçek bir CI timeout'u yerinde kalmalı. Ayrıca bütçeyle sınırlı bir çalıştırma eksiksiz bir denetim değil: pull request yorumları kaç testin dışarıda bırakıldığını belirtiyor ve birleştirmeden önce tam seçim çalıştırılmalı. Shadow modunda, bütçenin dışarıda bıraktığı bir başarısızlık nedeni budget olan bir miss olarak kaydediliyor; böylece ekipler bir bütçenin kendi depolarında neye mal olduğunu ölçebiliyor.

Jest, Java ve düzeltmeler

Jest seçimi artık Node.js gerektirmeyen gerçek bir JS/TS import grafiği kullanıyor; import.meta.glob gibi hesaplanmış importlar da buna dahil. Java seçimi, modül başına build dosyası kapsamıyla, çok modüllü yapılar dahil Maven ve Gradle'ı kapsıyor. Planlanmamış eklemeler arasında addFileAttribute olmadan Jest desteği, JUnit 5 DisplayName testleri için yeniden çalıştırma, Go workspace'leri ve iç içe modüller, bir GitLab Tests sekmesi, go list'in artık go.mod'u düzenlememesi sağlayan bir değişiklik ve altı hata düzeltmesi var — bunların üçü siftwise'ın testleri sessizce atlamasına yol açıyordu.

Yükseltme

Sürüm, sunucu başlatıldığında otomatik çalışan iki eklemeli veritabanı migration'ı içeriyor ve bakımcı sunucu ile istemcilerin birlikte güncellenmesini öneriyor. Yeni bir CLI, 0.2 sunucusuyla bütçeler dışında zarif biçimde geriliyor; bütçeler sessizce bırakılamıyor: Action, GitLab ve MCP bir uyarıyla tam suite'e geri düşüyor, CLI ise bir hatayla çıkıyor. Eski bir CLI yeni bir sunucuyla değişmeden çalışıyor. Proje artık kendi CI'sında her pull request ve push'ta siftwise'ı çalıştırıyor ve ilk iki dış katkıcısını kazandı.

Neden önemli

İlk başarısızlığa kadar geçen süre, geliştiricilerin gerçekten hissettiği gecikmedir. Bunu, hangi testlerin çalıştığını değiştirmeden, yeniden oynatılan rdflib geçmişinde bir çalıştırmanın kabaca üçte birinden %2'nin altına indirmek, self-hosted CI için anlamlı bir verimlilik kazancı. Sabit ve belgelenmiş puanlama formülü davranışı opak değil denetlenebilir kılıyor; ve ters yöne giden sayıları yayımlamak — import derinliği gerilemesinden yayımlanmayan maliyet farkındalıklı sıralamaya kadar — verimlilik iddialarını inandırıcı kılan türden kanıt oluşturuyor.