Açık konuşayım, bu tıp değişiklikleri ilk duyduğumda genellikle “ya yine ne çıktı başımıza” diye iç geçiririm. Ama GitHub’ın rate_limit endpoint’inden code_scanning_upload alanını kaldırma kararı, aslında uzun zamandır birçok ekibin kafasını kurcalayan bir işi nihayet toparlıyor. Yanı şikayet edecek bir tarafım yok, hatta tam tersi. İyi bile olmuş.
Bunu yaşayan biri olarak söyleyeyim, 19 Mayıs 2026. Tarihî bir kenara not edin. O gün geldiğinde, GitHub REST API’sinde /rate_limit endpoint’ını çağırdığınızda artık code_scanning_upload diye bir alan göremeyeceksiniz. Sadece core kalacak. Işin aslı, code scanning yüklemeleri zaten arkada hep core havuzundan sayılıyordu, ayrı bir sayaç varmış gıbı görünmesi biraz kafa karıştırıyordu.
Bu yazıda hem teknik tarafı hem de bunun Türkiye’deki ekipler açısından ne anlama geldiğini konuşacağım (eh, fena değil). Bir de küçük bir hikayem var, son projemden — ona da geleceğim. Hani bazen ufak görünen değişiklikler ölür ya, sonra asıl derdin oradan çıktığını fark edersiniz; işte bu konu da biraz öyle.
Olay Aslında Ne? Kısaca Özet
GitHub’ın /rate_limit endpoint’i, API kullanım kotanıza bakmanın en düz yolu. Çağırıyorsunuz, kalan hakkı söylüyor. Şimdiye kadar bu yanıtın içinde code_scanning_upload diye ayrı bir alan da vardı; dışarıdan bakınca bağımsız gıbı duruyordu, ama işin içi öyle değilmiş.
Asıl mesele şu: code_scanning_upload, core ile aynı kotayı paylaşıyordu. Yanı SARIF dosyası yüklerken sayaç iki yerde de oynuyor sanıyordunuz, ama gerçekte tek havuz vardı. Aynı sudan içiyorlardı, açık konuşayım.
İtiraf edeyim, Bu da hâliyle kafa karıştırıyordu. “Benim code_scanning_upload tarafında 5000 hakkım var” diye rahatlayan bir ekip, eğer core‘u zaten tükettiyse upload yapamıyordu. Tipik bir UX sürprizi bu; teknik olarak çalışıyor, ama insanı yanlış yere götürüyor.
GitHub bu alanı kaldırınca aslında bir yanılgıyı temizliyor. Kötü haber gıbı durmuyor bence — daha çok düzenleme. Ben bu tarz “az ama doğru” dokümantasyon hamlelerini severim.
Önce ve Sonra: JSON Yanıtı
Görsel olmadan biraz kuru kalıyor, o yüzden net hâliyle bakalım. Mevcut cevap şu şekilde dönüyor şu an:
{
"resources": {
"core": {
"limit": 5000,
"used": 1,
"remaining": 4999,
"reset": 1372700873
},
"code_scanning_upload": {
"limit": 5000,
"used": 1,
"remaining": 4999,
"reset": 1372700873
}
}
}19 Mayıs 2026’dan sonra işe tablo sadeleşiyor, yanı sadece core kalıyor:
{
"resources": {
"core": {
"limit": 5000,
"used": 1,
"remaining": 4999,
"reset": 1372700873
}
}
}Bitti işte. Tek satır gidiyor gıbı görünüyor. Bazen sorun tam orada çıkıyor; parse eden script’lerinizde KeyError, başka bir tarafta da NullReferenceException patlayabilir. Evet, ufak değişiklikler bazen en can sıkıcı yerden vuruyor (ciddiyim)
Etkilenen Kim? Bunu Ciddiye Almalı mıyım?
Şöyle ki, Bakın şimdi, açık konuşayım: Eğer ekibiniz GitHub Advanced Security (GHAS) kullanıyorsa. CI/CD pipeline’larınızda SARIF upload yapan bir akış varsa, hele bir de bunun etrafına “rate limit’e takılır mıyız” diye kontrol koyduysanız, bu değişiklik size dokunabilir. Ufak gıbı duruyor, ama bazen en sessiz değişiklikler en çok baş ağrıtanlar oluyor.
İtiraf edeyim, Ama herkes için durum aynı değil. Hani ilk bakışta “herkesi vurur” gıbı görünüyor ya, öyle değil; ben kafamda şöyle bir tablo oturttum, paylaşayım:
| Kullanım Senaryosu | Etkilenir mi? | Yapılacak |
|---|---|---|
Sadece actions/upload-sarif kullanıyor |
Hayır | Hiçbir şey |
Custom script /rate_limit parse ediyor |
Evet | Kodu güncelleyin |
Monitoring dashboard’unda code_scanning_upload grafiği var |
Evet | core‘a geçirin |
| Sadece okuma için Octokit kullanıyor | Belki | SDK güncel mi kontrol edin |
| Kendi SARIF uploader’ınızı yazdınız | Evet | Rate limit kontrol bloğunu refactor edin |
Yanı etkilenen alan aslında dar. Ama işin komik tarafı şu: dar olması rahatlatıcı gıbı geliyor, sonra bir bakıyorsunuz o dar alan tam da sizin pipeline’a denk gelmiş. Peki, peki neden? Çünkü böyle şeyler genelde toplantıda değil, gece yarısı build sırasında patlıyor.
Türkiye’deki Ekipler Açısından Durum
Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de GHAS adoption’u hâlâ ağır ağır ilerliyor. Geçen yıl bir bankacılık projesinde yaklaşık 40 repo’yu GHAS’a almıştık; oradaki DevOps ekibinden Mehmet bey de “biz rate limit’e takılır mıyız diye stresleniyoruz,. Gerçekte hiç takılmadık” demişti. Haklıydı aslında; günde belki 200-300 push var, SARIF upload sayısı da aşağı yukarı aynı,. 5000 limit yanında bu baya küçük kalıyor.
İtiraf edeyim, Türkiye’deki orta ölçekli yazılım ekiplerinin çoğu bu değişiklikten haberdar bile olmayacak ve etkilenmeyecek. Çünkü zaten o seviyede monitoring kurulu ölmüyor, hani ihtiyaç başka tarafta kalıyor. Bunu eleştiri diye değil, sahada gördüğüm gerçek diye söylüyorum; bazen ekipler önce işi yürütüyor, sonra ölçmeye başlıyor.
Gel gelelim büyük telekomlarda veya çok-repo’lu finans kurumlarında tablo değişiyor. Oralarda rate limit dashboard’ları var, bazıları PowerBI’a kadar bağlanmış durumda; bir telekom müşterimde tam olarak böyle bir Grafana panel’i vardı ve code_scanning_upload ayrı bir tile olarak görünüyordu. O panel’in sahibi bu yazıyı okumalı yanı.
Çok konuştum, örnekle göstereyim. Maintainer Month 2025: Kodun Arkasındaki İnsanlar Önemli yazımızda bu konuya da değinmiştik.
Tam da öyle.
Kodunuzda Ne Değişecek? Pratik Örnekler
Bilmem anlatabiliyor muyum, Şimdi işin can alıcı yerine gelelim. Eğer elinizde bir Python script varsa. O script şöyle bir şey yapıyorsa, küçük gıbı görünen ama can sıkan bir değişiklik sızı bekliyor. Bu konuyla ilgili Microsoft OpenJDK Nisan 2026 Yaması: Sahadan Notlar yazımıza da göz atmanızı tavsiye ederim.
import requests
response = requests.get(
"https://api.github.com/rate_limit",
headers={"Authorization": f"Bearer {token}"}
)
data = response.json()
# ESKİ KOD — 19 Mayıs 2026'dan sonra patlayacak
scanning_remaining = data["resources"]["code_scanning_upload"]["remaining"]
if scanning_remaining Bunu artık şöyle güncellemeniz gerekiyor. Kısa versiyon bu. Ama durun, burada ufak bir ayrıntı var: GitHub tarafında sayaç mantığı biraz kaydığı için, eski alan adıyla devam etmek sızı sessizce yanıltabiliyor.
import requests
response = requests.get(
"https://api.github.com/rate_limit",
headers={"Authorization": f"Bearer {token}"}
)
data = response.json()
# YENİ KOD — core üzerinden takip
core_remaining = data["resources"]["core"]["remaining"]
if core_remaining < 100:
print("Dikkat, core API kotası azalıyor (code scanning dahil)!")
Şunu fark ettim: Daha temkinli yazmak istiyorsanız — ben açık konuşayım, çoğu zaman en sağlıklısı da bu — .get() ile fallback koyabilirsiniz. Hem eski response’u yakalarsınız hem de yeni yapıda duvara toslamazsınız.
# Geriye uyumlu, hem eski hem yeni response ile çalışır
resources = data.get("resources", {})
scanning = resources.get("code_scanning_upload")
core = resources.get("core", {})
remaining = (scanning or core).get("remaining", 0)
Bu yaklaşım transition döneminde iş görüyor. Yanı şimdi ile Mayıs arası biraz idare eder, sonra zaten temizliği yaparsınız. Evet, tam da öyle.
Bir Hata Hikâyesi
Geçen ay buna benzer bir refactor sırasında ben de küçük bir çukura düştüm. Bir müşterinin self-hosted runner ortamında SARIF upload akışını koşturuyorduk; kodu güncellerken code_scanning_upload referansını kaldırıp core‘a geçtim, lokalde test ettim, her şey yolunda göründü ama production’a çıkınca tablo değişti (bizzat test ettim)
Sebep şuydu: bizim kullandığımız PAT token core limit’ını değil, GitHub App installation token limit’ını baz alıyordu; yanı iş sandığımdan biraz daha kayganmış meğer. Token tipine göre resources.core yerine resources.actions_runner_registration gıbı başka alanlar da karşınıza çıkabiliyor (ciddiyim)
Araya gireyim: Neyse uzatmayayım, buradaki ders net: sadece “code_scanning_upload”u “core” ile değiştirip geçmeyin. Önce token tipine bakın, sonra response yapısını kontrol edin. CVE-2026-3854: git push Üzerinden GitHub’da RCE Vakası yazımda da değinmiştim; token yönetimi bizim tarafta hep ikinci plana atılıyor ama sonra en çok baş ağrıtan yer orası oluyor (bizzat test ettim). Siz ne dersiniz?
Neden Bu Değişiklik Aslında İyi Bir Şey?
Ben açık konuşayım: API tasarımında “yanıltıcı netlik” en kötü işlerden biri. Kullanıcıya iki ayrı sayaç gösterip, sonra ikisinin de aynı havuzdan beslendiğini söylemek var ya, işte orada iki sayaç yok; bir sayaç ve üstü örtülmüş bir gerçek var.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için SQL MCP Server’ı App Service’te Çalıştırmak: Container’sız yazımıza bakabilirsiniz.
GitHub bunu fark etmiş ve toparlıyor. İyi de yapıyor. Bazı ekipler bu tarz “deprecated ama hâlâ ekranda” kalıntıları yıllarca taşıyor, hani geri uyumluluk diye diye uzatıyorlar; ama işin aslı, temiz tutmak çoğu zaman daha az baş ağrısı çıkarıyor.
X-RateLimit-Resource response header’ını kullanabilirsiniz. Bu header, isteğin hangı kotadan düştüğünü söyler — daha doğru bir yaklaşım.
Enterprise vs Küçük Ekip Stratejisi
Şimdi pratik tarafa geçelim, çünkü teori güzel de sahada durum biraz başka oluyor. Küçük ekiplerde çoğu zaman ortalığı karıştırmaya gerek yok; ama büyük organizasyonlarda bir header değişikliği bile monitoring zincirinde sessizce yankı yapabiliyor, o yüzden gözden kaçırmamak lazım (buna dikkat edin)
Şöyle düşünün: 5-10 geliştiriciyle çalışan bir ekipte bu konu büyük ihtimalle kimsenin gününü bozmaz; ama 50+ geliştirici ve GHAS aktifse, CI/CD akışlarında küçük görünen referanslar bile raporları şaşırtabiliyor. Peki neden? Çünkü sistemler çoğu zaman beklediğimizden daha fazla birbirine bağlı oluyor.
- Küçük ekipseniz (5-10 dev): Hiçbir şey yapmayın. Kullanmıyorsanız bu alanı, görmezden gelin. Mayıs geldiğinde belki size uyarı maili bile düşmez.
- Orta ölçek (50+ dev, GHAS aktif): CI/CD pipeline’larınızda
/rate_limitreferansı arayın.grep -r "code_scanning_upload"yapın repo’larda. Çıkanları güncelleyin. (bence en önemlisi) - Enterprise (büyük finans, telekom): Monitoring sisteminizi (Datadog, Grafana, Splunk neyse) gözden geçirin. Dashboard’lardaki
code_scanning_uploadtile’larıcore‘a migrate edin. Alerting kurallarını güncelleyin. (bence en önemlisi)
Açıkçası, Evet.
Ha bu arada — eğer GHAS dışında Defender for Cloud entegrasyonunuz varsa, Defender for Cloud + GHAS Entegrasyonu: Code-to-Cloud GA yazımı okumanızı tavsiye ederim. Orada code-to-cloud akışında SARIF’in nasıl taşındığını anlatmıştım; yanı konu sadece rate limit değil, uçtan uca güvenlik akışının nereye oturduğu da önemli (evet, doğru duydunuz)
Eh, Tam da öyle.
Maliyet ve Kota Tarafında Ne Düşünmeli?
Eh, Bu değişikliğin doğrudan bir maliyet etkisi yok (buna dikkat edin). Yanı aboneliğin fiyatı aynı kalıyor, kota da azalmıyor; core kategorisi GitHub Enterprise Cloud için saatte 5.000 istek seviyesinde duruyor (kullanıcı bazında, PAT ile) ya da GitHub App’ler için 15.000 istek/saat, rakamlar burada değişmemiş durumda.
Ama işin içinde küçük bir kıvrım var, hani ilk bakışta insanın aklına takılıyor: “SARIF upload ile core aynı havuzdaysa, ben repos, issues, pulls gıbı endpoint’leri sık kullanırken SARIF upload’ım da bundan payını alır mı?” Evet, alır. Fakat bu yeni bir şey değil; eskiden de böyleydi, sadece çoğu kişi bunu net görmüyordu.
Durun, bir saniye.
Pratikte 5.000/saat limiti GHAS upload için baya iş görüyor. Ben bir müşteride saatte 800 build dönen bir mono-repo gördüm (üstelik ekip sürekli deploy peşindeydi), yine de limit’in yanına yaklaşmıyorlardı; açık konuşayım, orada panik edecek bir tablo yoktu.
İlk Adım Olarak Yapılacaklar
- Repolarınızda
grep -r "code_scanning_upload"çalıştırın — ciddi fark yaratıyor - Çıkan dosyaları liste yapın — bunu es geçmeyin
- Her birinde fallback’li okumaya geçirin (yukarıdaki
.get()örneği gıbı) - Monitoring dashboard’larınızı kontrol edin — bunu es geçmeyin
- 19 Mayıs 2026’dan önce production’a deploy edin
Daha açık söyleyeyim, şunu fark ettim: Evet. Bu kadar basit görünüyor.
Yanı, Aşırı büyük bir iş değil, ama küçük diye geçerseniz sonra can sıkan bir incident’e dönebiliyor; yanı lafı gevelemeden söyleyeyim, şimdi toparlamak çok daha rahat.
Sıkça Sorulan Sorular
code_scanning_upload alanı tamamen mi kalkıyor, yoksa yerine başka bir şey geliyor mu?
Tamamen kalkıyor. Yerine yeni bir alan gelmiyor — aslında zaten core ile aynı havuzu kullanıyordu ki. Code scanning upload istekleriniz core kotasından düşmeye devam edecek,. Pratikte hiçbir şey değişmiyor.
Bu değişiklik GitHub Enterprise Server’ı da etkiliyor mu?
GitHub Cloud için kesin tarih 19 Mayıs 2026. Enterprise Server’a da geleceğini bekleyebilirsiniz, ama ne zaman geleceği için versiyon-spesifik release notes’a bakmanızı öneririm (inanın bana). Tecrübeme göre Cloud ile Server arasında genelde 6-12 aylık bir gecikme oluyor.
Şimdi gelelim işin can alıcı noktasına.
actions/upload-sarif kullanıyorum, kodumu güncellemek zorunda mıyım?
Hayır, gerek yok. GitHub’ın resmî action’ları zaten kendi içlerinde güncelleniyor. Yanı mesela sadece kendi yazdığınız custom script’lerde /rate_limit parse ediyorsanız endişelenin — stock action’lar size dokunmuyor.
Octokit gıbı SDK’lar otomatik olarak güncellenecek mi?
Evet, ama versiyon güncellemesi yapmanız gerekiyor. Octokit (JS,.NET, Python, Ruby) yeni response yapısına uyacak şekilde release alıyor. Açıkçası, pin’lediğiniz versiyonu bir kontrol edin. Gerekirse Mayıs öncesi güncelleyin — sonra uğraşmak zorunda kalmayın.
Kendi rate limit takıp sistemim için en doğru yaklaşım ne?
Her API isteğine GitHub zaten X-RateLimit-* header’ları ekliyor. Hani X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Resource gıbı. Bunlar varken /rate_limit endpoint’ını ayrıca çağırmanıza gerek kalmıyor. Bence en temiz yol bu — polling yerine reactive monitoring olarak kurarsanız hem daha verimli hem çok daha az karmaşık oluyor.
Kaynaklar ve İleri Okuma
GitHub REST API: Rate Limit Endpoint Resmî Dokümantasyonu
Rate Limits for the REST API — Detaylı Açıklama
GitHub Changelog — Tüm Deprecation Duyuruları
SARIF Dosyası Upload Etme Rehberi
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
