GitHub Actions artık YAML anchor ve alias destekliyor; merge key ise hâlâ desteklenmiyor

Anchor ve alias artık resmî

GitHub.com üzerindeki GitHub Actions workflow'ları artık YAML anchor ve alias kullanabiliyor ve bu destek folklor olarak bırakılmak yerine resmî belgelere yazıldı. Bir dev.to yazısına göre, workflow yapılandırmalarını yeniden kullanmaya dair referans sayfasında "YAML anchors and aliases" başlıklı bir bölüm yer alıyor; bu bölüm, yeniden kullanmak istediğiniz içerik için ampersand işaretini ve onu tekrarlayan yıldız işaretini açıklıyor, YAML belirtimine bağlantı veriyor ve iki örnek sunuyor: iki job arasında bir env map'i paylaşmak ve bir job yapılandırmasının tamamını yeniden kullanmak.

Bölüm yeni ve tarihlenebilir durumda. github/docs deposundaki belge dosyasının commit geçmişi 17 Eylül 2025'e uzanıyor ve bölümü başlatan commit, başlığı, açılış cümlesini, her iki örneği ve ürün koşulunu tek bir değişiklikle ekliyor. Yazının dikkatle belirttiği gibi, o tarih belgeyi sabitliyor, runtime'ı değil: GitHub bu iddiayı yayınlamaya ne zaman başladığını söylüyor, herhangi bir parser'ın ne zaman değiştiğini değil.

Ürün koşulu dikkat deserve ediyor... sayfanın tamamı GitHub Free, Pro ve Team, Enterprise Cloud ve Enterprise Server için yayımlanıyor, ancak anchor bölümü yalnızca ilk ikisini seçen bir koşulla sarılmış. Bu nedenle belge, özelliği Enterprise Server için iddia etmiyor ve her iki üründe de yeniden kullanılan bir workflow, anchor'ların her ikisinde çalıştığını varsaymamalı.

Parser ne yapıyor

Uygulama tarafında, actions/runner deposunda yayımlanan workflow parser'ı AllowAnchors adında bir parse seçeneği ortaya koyuyor. Seçenek kapalıyken reader, bir skalar üzerindeki, bir mapping başlangıcındaki veya bir sequence başlangıcındaki anchor'ı "Anchors are not currently supported. Remove the anchor 'common'" tarzında bir iletiyle reddediyor. Açıkken reader, anchor'ları konuma göre kaydediyor ve bir alias ile karşılaştığında onları yeniden oynatıyor; hiç görmediği bir anchor'a işaret eden alias için ise farklı bir hata veriyor. GitHub'ın öncesi doğrulama servisi açık kaynaklı olmadığından yazı, o servisin hangi ayarı kullandığını iddia etmiyor; yayımlanan parser'ın sunduğunu ve belgelerin söylediğini aktarıyor.

Merge key farklı bir yapı

<< şeklinde yazılan merge key aynı özelliğin parçası değil. Anchor ve alias YAML parsing katmanı tarafından tanımlanırken, merge key onun üzerinde uygulanan bir uzlaşım; dolayısıyla bir reader ilk ikisini destekleyip üçüncüsünü iki açı paranteziyle yazılmış sıradan bir key olarak içinden geçirebilir.

Hata biçimlerinin kafa karıştırıcı olması bu yüzden. Workflow kökü ve her job, sabit özelliklere ve gevşek key'lere sahip olmayan mapping'lerdir; dolayısıyla orada bir merge key, yazarın yazdığını düşünmediği bir key'i adı veren bir unexpected-value hatası üretir. Ancak her mapping sabit değildir: workflow düzeyindeki bir env map'i boş olmayan herhangi bir dizgeyi key olarak kabul eder, dolayısıyla oraya yerleştirilen bir merge key sessizce bir ortam değişkeninin adı olarak kabul edilir. Merge key belgelerde hiçbir yerde görünmüyor ve yayımlanan workflow şemasında bir özelliği yok.

Bunun yerine ne kullanmalı

Yazı, tam değerleri — örneğin eksiksiz bir map'i veya eksiksiz bir job'ı — anchor'layıp alias'lamayı öneriyor; belgelenmiş örneklerin yaptığı da tam olarak bu. Bir map'i genişletmek merge key'in işiydi ve burada onun yerine geçecek bir şey yok. Sınırlar ötesi tekrarlar için ise bildirilen arayüzlere işaret ediyor: paylaşılan adımlar için composite action'lar ve paylaşılan job'lar için workflow_call ile tipli girdilere sahip yeniden kullanılabilir workflow'lar; ikisi de dosyaları ve depoları aşar ve ürün koşulu taşımaz. Anchor'lar en iyisi tek bir dosya içindeki küçük tekrarlar için saklanmalı; bağımlılığı not eden bir yorumla birlikte, böylece Enterprise Server'a geçiş kaza değil bilinçli bir karar olur.

Neden önemli

Yıllarca, GitHub Actions workflow'larının anchor kullanıp kullanamayacağı sorusunun doğru cevabı hayırdı ve çok sayıda cevap ile blog yazısı hâlâ öyle diyor. Bu öneri artık GitHub.com ve Enterprise Cloud için geçerliliğini yitirdi ama Enterprise Server için doğru kalmaya devam ediyor; bu da workflow'larını ürünler arasında paylaşan ekipler için sessiz bir ayrışma yaratıyor. Merge key daha da garip bir konumda: bazı konumlarda adıyla reddediliyor, diğerlerinde ise harfi harfine bir ortam değişkeni adı olarak kabul edilir. Karşınızda olan üç durumdan hangisi olduğunu — eski bir öneri, bir ürün kapısı ya da hiç desteklenmemiş bir yapı — tanımak, hızlı bir düzeltme ile uzun bir debug seansı arasındaki farktır.