GitHub Actions’a $/ Söz Dizimi: Aynı Repo’daki Aksiyonlara
GitHub Actions, aynı depo içinde tanımlı aksiyonları ve yeniden kullanılabilir iş akışlarını çağırırken uzun süredir sürdürülen bir kısıtlamayı ortadan kaldıran yeni bir söz dizimi getirdi. Artık uses: alanında $/ ile başlayan bir değer kullanarak çalışan iş akışının bulunduğu repoyu ve o an çalışan commit’i doğrudan referans verebiliyorsunuz. İlk bakışta küçük bir sözdizimi eklemesi gibi görünse de kurumsal güvenlik politikalarıyla uyum ve iç referansların tutarlılığı açısından önemli bir boşluğu dolduruyor.
$/ söz dizimi ne yapıyor?
$/ ile başlayan bir uses: değeri, iş akışının kendi deposuna ve o anda çalışmakta olan tam commit’e çözümleniyor. Ayrıca bir checkout adımına da gerek kalmıyor; aksiyonun kaynağını çalışma alanına indirmek zorunda kalmadan aynı depodaki bir aksiyonu ya da yeniden kullanılabilir iş akışını doğrudan çağırabiliyorsunuz.
Yeni söz dizimi, çalışma alanına göreli ./ söz diziminin çalıştığı her yerde geçerli. Şu kullanım noktalarını kapsıyor:
- İş akışı adımları (
steps) - Composite action adımları
- İç içe (nested) composition yapıları
- Yeniden kullanılabilir iş akışı (reusable workflow) çağrıları
Kısacası, aynı repo içinde bir aksiyonu veya iş akışını nerede referans veriyor idiyseniz orada $/ söz dizimini kullanabilirsiniz.
Önceki yaklaşımın sorunları
Bu özellik gelene kadar kendi deponuzdaki bir aksiyonu referans vermenin pratikte iki yolu vardı. Birincisi ./ göreli yolunu kullanmaktı, ama bu yol öncesinde bir checkout adımı çalıştırılmasını gerektiriyordu. İkincisi ise sürümü sabitlemek, yani bir tag ya da commit SHA değerini elle yazmaktı.
Her iki yaklaşımın da kendine göre maliyetleri vardı. checkout gereksinimi ekstra adım ve bakım demekti. Sürümü sabit kodlamak ise iç referansların, iş akışını çağıran tarafın sabitlediği sürümle senkronizasyonunu kırıyordu. Kaynakta ifade edildiği gibi bu yaklaşım aynı zamanda commit SHA pinning’in (tam uzunlukta commit SHA sabitleme) sağladığı güvenceyi sessizce zayıflatıyordu: Dıştan gelen çağrı bir SHA’ya sabitlense bile iç referans farklı bir sürüme işaret edebiliyordu.
Tutarlılık ve güvenlik açısından ne değişiyor?
Self-repository referansları sayesinde aynı depodaki kardeş aksiyonlar ve iş akışları, zaten üzerinde çalıştığınız ref ile otomatik olarak eşleşiyor. Çağıran taraf iş akışını tam uzunlukta bir commit SHA’ya sabitlese bile iç referanslarınız bu commit ile tutarlı kalıyor. Böylece iç ve dış referanslar arasındaki sürüm sapması sorunu kendiliğinden ortadan kalkıyor.
Bu davranış, güvenlik politikaları söz konusu olduğunda özellikle kritik. GitHub Enterprise Cloud tarafında, aksiyonların tam uzunlukta commit SHA ile sabitlenmesini zorunlu kılan bir kurumsal politika bulunuyor. Kaynak, self-repository referanslarının bu politikayı, kendi aksiyonlarını çağıran iş akışları için uygulanabilir hale getirdiğini belirtiyor. Yani daha önce iç referansları nedeniyle bu politikayı uygulamakta zorlanan iş akışları, $/ söz dizimi ile hem SHA pinning gereksinimini karşılayabiliyor hem de iç referanslarının otomatik olarak doğru commit’e çözümlenmesinden yararlanabiliyor.
Tavsiye edilen kullanım ve gereksinimler
GitHub, bir repo içinde aksiyonları ve yeniden kullanılabilir iş akışlarını birleştirmek için artık self-repository referanslarını önerilen yöntem olarak konumlandırıyor. Yani ./ tabanlı yaklaşımın ya da sürüm sabit kodlamanın yerine, aynı depo içi kompozisyonlarda öncelikli tercih $/ söz dizimi olacak.
Özelliğin kullanılabilirliğiyle ilgili iki noktanın altı çiziliyor:
- Self-repository referansları github.com üzerinde kullanılabilir durumda.
- Özellik, GitHub Actions runner’ının 2.336.0 veya daha yeni bir sürümde olmasını gerektiriyor.
Kendi runner’larını (self-hosted) kullanan ekiplerin $/ söz dizimine geçmeden önce runner sürümlerini kontrol etmesi gerektiği, bu gereksinimden çıkarılabilecek doğal bir sonuç. Kaynak bunun ötesinde ek bir uyumluluk detayı vermiyor; farklı senaryoları test ederken resmi belgelere başvurmakta fayda var.
Kısa bir değerlendirme
Yeni söz dizimi ilk bakışta yalnızca daha temiz bir yazım biçimi sunuyormuş gibi görünebilir. Ancak kaynağın vurguladığı iki nokta değişikliği daha kritik bir yere yerleştiriyor: checkout bağımlılığının ortadan kalkması ve iç referansların çağıran ref ile otomatik hizalanması. Bu ikisi bir araya geldiğinde hem iş akışı bakım yükü azalıyor hem de commit SHA sabitlemeye dayalı güvenlik politikaları iç referanslara rağmen anlamını koruyor. Aynı depo içinde birden fazla composite action, nested composition veya reusable workflow kullanan projeler için doğrudan uyarlanmaya değer bir iyileştirme.
Kaynaklar ve İleri Okuma
- GitHub Changelog: Reference same-repository actions with self-repository syntax
- GitHub Docs: Finding and customizing actions
- GitHub Docs: Enforcing policies for GitHub Actions in your enterprise
- GitHub Community: Announcements
- GitHub Actions 2026 Güvenlik Yol Haritası: Sırada Bizi Neler Bekliyor?
- GitHub Actions Nisan 2026 Güncellemeleri
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.
2 comments