GitHub, repository ruleset’leri içindeki Restrict code coverage seçeneğinin artık genel kullanıma açık REST API üzerinden yönetilebildiğini duyurdu. Daha önce yalnızca web arayüzünden yapılandırılabilen kod kapsama (code coverage) kuralı artık programatik olarak oluşturulabiliyor, güncellenebiliyor, okunabiliyor. Aynı kapsama eşiğini çok sayıda depoda arayüzden tek tek tanımlamak yerine mevcut otomasyon veya infrastructure-as-code akışınıza bağlayabiliyorsunuz.
Restrict code coverage kuralı ne yapıyor?
Bu ruleset seçeneği, bir depoda kod kapsamayla ilgili iki tür koşul tanımlamanıza izin veriyor:
- Minimum kod kapsama yüzdesi: Satır kapsamı (line coverage) temel alınarak belirlenen bir alt sınırın altına düşen değişikliklerin engellenmesi.
- Maksimum tolere edilebilir kapsama düşüşü: Bir pull request’in kapsama oranında yaratabileceği düşüşün üst sınırının tanımlanması.
İki koşul farklı işlere yarıyor. Birincisi sabit bir hedef yüzde dayatıyor, ikincisi kapsama oranının zaman içinde erimesini engelliyor. Uzun ömürlü ve çok katkı alan depolarda mutlak bir hedef yerine mevcut seviyeyi koruma yaklaşımı çoğu zaman daha uygulanabilir oluyor, kural iki yaklaşımı da destekliyor.
Kural arayüzde zaten vardı, yeni olan aynı yapılandırmanın REST API üzerinden okunup yazılabilmesi. Duyuruda API desteğinin generally available (genel kullanıma açık) olduğu belirtiliyor, yani önizleme aşamasında değil.
Neden API desteği fark yaratıyor?
Ruleset’lerin arayüzden yönetilmesi tek bir depo için sorun çıkarmaz. Onlarca ya da yüzlerce depoyu yöneten ekipler içinse her deponun ayarlar ekranına girip aynı eşiği tanımlamak hem zaman alıyor hem de tutarsızlığa açık bir süreç. GitHub’ın duyuruda vurguladığı fayda da bu, kapsama gereksinimlerini çok sayıda depoda tutarlı biçimde yönetmek ve bunu mevcut infrastructure-as-code iş akışlarına dahil etmek.
API desteği, uygulamada şu tür senaryoları mümkün kılıyor:
- Yeni bir depo açıldığında standart kapsama kuralının otomatik olarak uygulanması.
- Mevcut depolardaki kapsama kurallarının programatik olarak okunup denetlenmesi (hangi depoda hangi eşik tanımlı, hangisinde kural yok).
- Eşiklerin merkezi bir yapılandırma kaynağından yönetilmesi ve değişikliklerin toplu biçimde yansıtılması.
Bu senaryolar, kuralın durumunun okunabilmesiyle anlam kazanıyor. Yazma kadar okuma da desteklendiği için uyumluluk kontrolü yapan araçlar yazmak mümkün hale geliyor.
Ön koşullar: Code Quality ve kapsama yüklemeleri
Kuralın çalışabilmesi için iki şart var. Birincisi, deponuzda GitHub Code Quality özelliğinin etkinleştirilmiş olması. İkincisi ise kod kapsama yüklemelerinin (code coverage uploads) yapılandırılmış olması. İkinci madde kuralın nasıl çalıştığını belirliyor. Kural kapsamayı kendi başına ölçmüyor, CI sürecinizin ürettiği ve GitHub’a yüklenen kapsama verisine dayanarak karar veriyor. Kapsama raporu üretmeyen ya da raporu GitHub’a iletmeyen bir depoda bu ruleset koşulunu tanımlamak beklenen sonucu vermez.
API desteğini kullanmayı planlıyorsanız otomasyon sırasını buna göre kurmakta fayda var. Önce kapsama üretimi ve yüklemesi çalışır duruma gelmeli, ruleset koşulu ondan sonra devreye alınmalı. Aksi halde kuralı programatik olarak yaymak, depoların yalnızca kağıt üzerinde korunuyormuş gibi görünmesine yol açabilir.
Hangi planlarda kullanılabiliyor?
GitHub’ın duyurusuna göre özellik GitHub Enterprise Cloud ve GitHub Team planlarında kullanılabiliyor. Data residency (veri ikamet) seçeneğiyle kullanılan GitHub Enterprise Cloud kurulumları da bu kapsama dahil. Buna karşılık özellik GitHub Enterprise Server üzerinde sunulmuyor.
Şirket içinde GHES kullanan ekipler için bu ayrım önem taşıyor. Bulut ve sunucu kurulumlarının bir arada bulunduğu karma ortamlarda, kapsama kuralını merkezi otomasyonla yaymaya çalışan bir script GHES tarafındaki depolarda karşılık bulmayacak, bunu baştan hesaba katmak gerekiyor. Duyuruda GHES için bir takvim ya da planlanan destek bilgisi paylaşılmıyor, dolayısıyla beklenti oluşturmadan mevcut durumu esas almak doğru olur.
Uygulamaya geçerken nelere dikkat etmeli?
Kapsama eşiklerini otomasyona bağlarken birkaç noktayı netleştirmekte fayda var. Kural satır kapsamı üzerinden çalışıyor, dolayısıyla branch ya da fonksiyon kapsamı gibi başka metrikleri ölçüt alan ekiplerin eşik değerlerini yeniden düşünmesi gerekebilir. Minimum yüzde ile maksimum düşüş toleransının farklı amaçlara hizmet ettiğini de unutmamak gerekir. İlki mutlak bir kalite tabanı, ikincisi mevcut seviyeyi koruma mekanizması. Depo olgunluğuna göre bu ikisinden birini ya da uygun görüyorsanız ikisini birden tanımlayabilirsiniz.
Ruleset koşullarının ayrıntılı davranışı ve API uç noktalarının kullanımı için birincil kaynak GitHub’ın resmi dokümantasyonu. Aşağıdaki bağlantılar, hem ruleset’ler için kullanılabilir kuralların listesini hem de kurallara ilişkin REST API uç noktalarını içeriyor.
Kaynaklar ve İleri Okuma
- GitHub Changelog: Manage the code coverage ruleset condition with the REST API
- GitHub Docs: Ruleset’ler için kullanılabilir kurallar
- GitHub Docs: Kurallar için REST API uç noktaları
- Code Scanning Default Setup Artık Özelleştirilebilir
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Bunu bekliyordum açıkçası, UI’dan tek tek ayarlamak onlarca repo olunca eziyetti. API ile artık bir script yazıp tüm repolara aynı coverage kuralını basabiliriz. Maksimum düşüş toleransı özelliği de mantıklı olmuş, sıfır tolerans bazen gereksiz PR blokluyordu.
Tam ihtiyacım olan şeymiş bu, coverage kuralını her repoya elle eklemek baya eziyet oluyordu. API ile toplu yönetebilmek CI/CD tarafında işleri epey kolaylaştırır. Maksimum düşüş toleransı kısmını da denemek lazım, PR’larda coverage’ın sessizce erimesini engeller gibi duruyor.
Bunu bekliyordum açıkçası, coverage kuralını UI’dan tek tek ayarlamak onlarca repo olunca tam işkenceydi. API ile artık Terraform tarafında da yönetebiliriz sanırım, deneyip döneceğim. Maksimum düşüş toleransı kısmı özellikle mantıklı olmuş, sert bir minimum eşikten daha kullanışlı.