GitHub Actions API’de Workflow Run Sayımı Artık “2.500+
GitHub Actions’ta workflow run sorgularının toplam kayıt sayısını hesaplama biçimi değişti. workflow, event, status, branch veya actor filtreleriyle arama yaptığınızda artık daha az kesin ama daha doğru bir toplam alıyorsunuz: bulunan kayıt sayısı 2.500’ü aşıyorsa GitHub tam rakamı hesaplamaya uğraşmıyor, doğrudan “2.500+” bildiriyor. Değişiklik hem GitHub Actions API hem de arayüz tarafında geçerli, github.com ile GitHub Enterprise Cloud üzerinde yayına alınıyor.
Tam olarak ne değişti?
Değişiklik üç maddeye iniyor:
- Sayfalama aynı kaldı. Sorgular önceki gibi en fazla 1.000 öğeye kadar sayfalanmış sonuç dönduruyor, yani tek bir sorgudan çekebileceğiniz kayıt hacminde bir değişiklik yok.
- Sayım için üst sınır geldi. Eşleşen kayıt sayısı 2.500’ü geçtiğinde kesin rakam yerine “2.500+” ifadesi raporlanıyor.
- Kapsam filtrelerle sınırlı. Bu davranış workflow, event, status, branch veya actor alanlarına göre yapılan aramalar için geçerli.
1.000 öğelik sayfalama sınırıyla 2.500’lük sayım eşiği birbirinden ayrı şeyler. Birincisi kaç kaydı geri alabileceğinizi belirliyor, ikincisi “kaç kayıt eşleşti?” sorusuna verilen cevabın ne zaman yuvarlanacağını.
Neden “daha az kesin” ama “daha doğru”?
İlk bakışta çelişkili duran bu ifadenin teknik bir gerekçesi var. GitHub’ın açıklamasına göre 2.500’den fazla kayıt getiren sorgular sıklıkla zaman aşımına uğruyordu ve sistem böyle durumlarda gerçek toplamı değil, zaman aşımı gerçekleşmeden önce sayabildiği kayıt sayısını dönduruyordu.
Ekranda ya da API yanıtında kesin görünen o sayı, aslında yarıda kesilmiş bir hesaplamanın kalıntısı olabiliyordu. Üstelik rakam çalıştırmadan çalıştırmaya oynuyordu; aynı filtreyle iki kez sorgu attığınızda iki farklı toplam görebiliyordunuz. Sabit bir eşik koyup “2.500+” demek tam sayı vermiyor ama en azından yanıltmıyor.
İkinci kazanım performans tarafında. Büyük sonuç kümelerinde tam sayım yapmaya çalışmamak sorgu maliyetini düşürüyor, GitHub’ın ifadesiyle müşteriler için genel performansı iyileştiriyor. Actions sekmesinde yoğun geçmişi olan depolarda liste görünümünün davranışı da bu sayede daha öngörülebilir oluyor.
Entegrasyonlarınız etkileniyor mu?
Etkilenme ihtimali olan senaryo net: Tek bir sorgudan 2.500’den fazla eşleşen workflow run bilgisine dayanan entegrasyonlar ve script’ler. Otomasyonunuz dönen toplam sayıyı bir metrik olarak kullanıyorsa, 2.500 eşiğini geçen durumlarda sayısal bir değer yerine “2.500+” biçiminde bir gösterimle karşılaşacaksınız.
GitHub bu durum için filtreleri daraltmayı öneriyor, örnek olarak da tarih aralığı eklemeyi gösteriyor: Sorguyu belirli bir zaman penceresine sıkıştırıp yalnızca ihtiyacınız olan çalıştırmaları hedefliyorsunuz. Sonuç kümesini eşiğin altına indirdiğinizde sayım yine kesin bir değer olarak geliyor.
Pratikte kontrol etmeniz gereken noktalar şunlar:
- Toplam sayım değerini parse eden kodunuz varsa, sayısal olmayan bir ifadeyi (“2.500+”) güvenli şekilde ele aldığından emin olun. Tipi doğrudan tam sayıya çeviren bir mantık burada hata üretebilir.
- Raporlama ve dashboard katmanında “toplam çalıştırma sayısı” gösteren panelleriniz varsa, eşik üstü durumlarda gösterimi nasıl yansıtacağınıza karar verin.
- Toplu veri çekme işlerinde sorguyu zaman dilimlerine, workflow’lara veya branch’lere göre bölerek çalıştırmayı düşünün. Bu hem eşiği aşmamanızı sağlar hem de sayfalama sınırıyla daha rahat çalışmanıza imkan verir.
Kimler için pratikte bir fark yaratmayacak?
Gündelik kullanımda Actions sekmesinde son çalıştırmalara bakan, belirli bir branch’teki başarısız run’ları filtreleyen ya da tek bir workflow’un geçmişine göz atan kullanıcıların çoğu için görünür bir fark olmayacak. Bu tür sorgularda sonuç kümesi genellikle 2.500’ün epey altında kalıyor, kesin sayım da gösterilmeye devam ediyor.
Fark, uzun geçmişe sahip ve yoğun CI trafiği olan depolarda hissediliyor; özellikle de geniş filtrelerle, örneğin yalnızca status’e göre tarama yapan otomasyonlarda. Zaman aşımı riskinin en yüksek olduğu alan da zaten burası, yani değişikliğin hedef kitlesi.
Özet
Sayfalama üst sınırı 1.000 öğede sabit, eşleşen kayıt sayısı 2.500’ü aştığında toplam “2.500+” olarak raporlanıyor. Değişiklik workflow, event, status, branch ve actor filtreleriyle yapılan sorguları kapsıyor, github.com ile GitHub Enterprise Cloud üzerinde devreye alınıyor. Yapılacak iş, 2.500’ü aşan sonuç kümelerine dayanan script’leri gözden geçirip filtreleri daraltmaktan ibaret.
Kaynaklar ve İleri Okuma
- Changes to query results in the GitHub Actions API and UI – The GitHub Blog
- GitHub REST API: Workflow runs dokümantasyonu
- GitHub Actions için üç yeni görünürlük ve kontrol özelliği
- GitHub Actions’ta 50 yeniden çalıştırma sınırı
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.
0 comments