GitHub Actions lockfile'ları herkese açık önizlemeye sunuldu; satır içi SHA pinleme yerine geçmeyi hedefliyor

dev.to'daki bir yazıya göre GitHub, Actions için iş akışı bağımlılığı lockfile'larını 14 Ekim 2026'da herkese açık önizlemeye taşıdı ve özelliği GitHub Enterprise Cloud (veri ikameti dahil), Team ve Free planlarında kullanıma açtı. Özellik, depo başına tek bir lockfile üretiyor; bu dosya bir iş akışının kullandığı her action'ın arkasındaki kesin commit'i, geçişli bağımlılıklar dahil kaydediyor. GitHub ayrıca, özelliği benimseyen depoların artık iş akışı dosyalarında commit SHA'larını satır içi pinlemesine gerek olmadığını belirtiyor.

Lockfile'ların çözdüğü sorun

İş akışı adımları action'lara çoğunlukla @v4 veya @v1 gibi değiştirilebilir etiketlerle başvurur; bunların her biri başka bir ekibin deposundaki basit bir git ref'idir. Bir etiketin arkasındaki commit, inceleyenlerin iş akışını onayladıktan sonra değişebilir ve deponuzda hangi commit'in gerçekten incelendiğini kaydeden hiçbir şey yoktur. Geleneksel çözüm, her action'ı tam commit SHA'sına pinlemektir — bu yaklaşım örneğin Lullabot'un mimari karar kaydında zorunlu tutulur — ve Renovate, Dependabot, pinact ve ratchet gibi araçlar bu pinleri güncel tutarken frizbee etiketleri SHA'ya dönüştürür. Ancak Andrew Nesbitt'in de belirttiği gibi, SHA pini yalnızca en dıştaki action'ı güvence altına alır: o action'ın etiketle çağırdığı bir yardımcı action hâlâ altınızda değişebilir.

Lockfile neyi kaydediyor

Her depoda .github/workflows/actions.lock konumunda tek bir dosya bulunur; bu dosya gh-actions-lock CLI uzantısıyla üretilir (gh extension install github/gh-actions-lock ile kurulur ve yazma erişimi gerektirir). GitHub'ın belgeleri, dosyanın asla elle düzenlenmemesi gerektiğini söylüyor. İş akışları tek tek ya da topluca kaydedilebilir. Dosyada, kaydedilen her iş akışını bağımlılıklarına bağlayan bir workflows bölümü ve her girdinin iş akışında adı geçen ref'i, sha1-... biçiminde çözümlenmiş commit'i ve GitHub'ın çalışma zamanında bir adın arkasındaki deponun hâlâ kilitlediğiniz depo olduğunu doğrulamasını sağlayan sahip ve depo kimliklerini sakladığı bir dependencies bölümü bulunur. Composite action'ların içinde çağrılan action'lar — iş akışı düzeyinde görünmez olanlar — üst girdilerinin uses listesinde yer alır. dev.to yazarı, biçimin bütünlük veya içerik hash alanı taşımadığını, yalnızca commit'i içerdiğini belirtiyor; ancak GitHub bunu açıkça söylemiyor.

Yaptırım dört parçadan oluşuyor

Lockfile üretimi, bir iş akışını kaydetme, CI'da gh actions-lock --verify çalıştırma ve 'Require lockfile' ilkesi birbirinden ayrı dört denetimdir ve yalnızca ilke, kimsenin kaydetmediği iş akışlarının çalışmasını engeller. Bir iş akışı kaydedildiğinde, kullandığı her action'ın lockfile'da bulunması gerekir. İş başladığında GitHub kaynak depo kimliğini, pinlenmiş commit'i ve tam sürüm etiketlerini denetler; yayımlanan CLI, depo kimliğini koruyan bir yeniden adlandırma ya da aktarımı (bu bir uyarı üretir), aynı adın arkasına gizlenmiş bambaşka bir depodan (bu çalışmayı engeller) ayırt eder.

Uygulamalı bir deneme

dev.to yazarı, gh-actions-lock v0.2.0 ile (Linux'ta gh 2.102.0) bir yayımlama iş akışı kaydetti. Araç üç action ile birlikte iki geçişli action'ı pinledi — geçişli ikili, composite actions/attest-build-provenance action'ının içinden geliyordu — ve iş akışındaki başvuruları @v4 ve @v1 yerine @v4.4.0 ve @v1.4.4 tam sürüm etiketlerine yeniden yazdı. Lockfile işlendikten sonra gh actions-lock --verify iş akışını geçerli bildirdi ve temiz bir şekilde çıktı.

Sınırlar ve olgunluk

Korumanın net sınırları var. Çağırdığınız yeniden kullanılabilir iş akışlarındaki bağımlılıklar kapsanmıyor, etiketle çekilen container imajları kilitlenmiyor ve bir lockfile, pinlenen kodun kendisinin güvenilir olup olmadığı konusunda hiçbir şey söylemiyor. CLI henüz 1.0 öncesi — dosya biçimi, bayraklar ve davranış sürümler arasında değişebilir — ve GitHub Enterprise Server desteklenmiyor. Belgeler de tutarsız: duyuruda plan kullanılabilirliğini Team ve Free'yi de içerecek şekilde düzelten bir editör notu varken, kurulum kılavuzu özelliği hâlâ GitHub Enterprise Cloud olarak tanımlıyor. Geliştirme hızla ilerliyor: v0.2.0 12 Ekim 2026'da geldi, 22 Ekim'de yayımlanan v0.3.0 ise yerel action işlemeyi değiştirdi, container imajı uyarıları ekledi ve doğrulamayı sıkılaştırdı. Yayımlanan test anlatımı v0.2.0'ı anlatıyor ve v0.3.0'a karşı yeniden çalıştırılmadı.

Neden önemli

CI iş akışına sahip herkes, okunabilir @v4 etiketleri ile SHA pinlemenin denetim izi arasındaki ödünleşimi, ayrıca düzinelerce iş akışında çok sayıda pini güncel tutmanın araç yükünü yaşamıştır. Lockfile'lar bunu tek bir makine tarafından üretilen, incelenebilir diff'te birleştiriyor ve satır içi pinlemenin açık bıraktığı geçişli action boşluğunu kapatıyor. Önizleme durumu, desteklenmeyen platformlar ile yeniden kullanılabilir iş akışı ve container imajı boşlukları düşünülünce akıllıca hareket, tek bir iş akışında sınırlı bir pilot yapmak — ve lockfile'ın ulaşmadığı her yerde SHA pinlerini korumak.