GitHub Actions lockfile’ı çalıştırılacak kodu sabitler, ancak CI’ın tamamını değil

Bir workflow, @v3 gibi bir etikete başvuruyorsa GitHub Actions’a güvenilebilir mi? Lockfile, etiket daha sonra başka bir commit’e taşınsa bile hangi action commit’inin çalıştırılacağını netleştirir. Ekip, bağımlılık güncellemelerini diff üzerinden inceleyebilir ve CI’da kullanılan actions’ların denetlenebilir bir listesini tutabilir. Uygulamadaki sınır şudur: lockfile, adımlar tarafından çağrılan actions’ları kapsar; job düzeyinde çağrılan reusable workflow ise ayrıca sabitlenmelidir. Açıklanan mekanizma GitHub Enterprise Cloud’da kullanılabilir.

Lockfile tam olarak neyi sabitler?

Dallara ve etiketlere verilen bağlantılar kullanışlıdır, ancak işaret ettikleri sürüm değişebilir. uses: octo-org/deploy-action@v3 gibi bir kayıt, bir etiket adına işaret eder; GitHub bu bağlantıyı çalıştırma sırasında bir commit’e çözümler. Proje sahibi etiketi başka bir commit’e taşırsa, bağımlılığı sabitlenmemiş sonraki çalıştırma farklı bir kod alabilir.

GitHub’ın lockfile belgelerine göre .github/workflows/actions.lock dosyası, bağımlılıklara verilen bağlantıları ve bunlara karşılık gelen commit SHA’larını, diğer actions’ların kullandığı actions’lar dâhil olmak üzere geçişli bağımlılıklarla birlikte saklar. Dosya, GitHub CLI uzantısı gh actions-lock tarafından oluşturulur; elle düzenlenmez.

Oluşturucu, workflow dosyalarındaki uses bağlantılarını da daha belirgin hâle getirebilir: örneğin, hareketli bir etikete verilen bağlantıyı daha somut bir bağlantıya dönüştürürken lockfile oluşturulduğunda bu etiketin çözümlendiği commit’i koruyabilir. Bu nedenle uygulama sırasında workflow ve lockfile değişiklikleri dâhil tüm diff incelenmeli, sabitlenen sürümün ekibin çalıştırmak istediği sürüm olduğu doğrulanmalıdır.

Böylece bağımlılık güncellemesi depoda görünür bir değişiklik hâline gelir: ekip commit değişikliğini inceleyebilir, tartışabilir ve olağan inceleme sürecinden geçirerek kabul edebilir. Lockfile, action kodunun denetlenmesine ve bağımlılıkların tutarlı tutulmasına yardımcı olur; ancak seçilen kodun güvenli olduğunu tek başına doğrulamaz.

Sabitlenmenin kapsamı nerede sona erer?

jobs.<job_id>.uses içinde çağrılan reusable workflow, onu çağıran deponun lockfile’ı tarafından sabitlenmez. Reusable workflow’un bağımlılıkları, workflow’un tanımlı olduğu depoya aittir. Çağrının kendisini sabitlemek için tam commit SHA belirtin; workflow’un actions’larını sabitlemek içinse kaynak depoda ayrı bir lockfile gerekir.

Lockfile, actions kodunu denetler; ancak action’a aktarılan parametreler, sırlar veya runner imajı gibi derlemenin diğer girdilerini kapsamaz. Şu belirli soruya yanıt verir: Hangi action kodu commit’i çalıştırılacak? Bu diğer öğeler kendi yönetim kurallarını gerektirir.

Bir başka özel durum, uses: ./ gibi bir yol üzerinden çağrılan yerel action’dır. GitHub talimatlarına göre gh actions-lock uzantısı yerel action yolunu sabitlemez veya analiz etmez. Böyle bir action başka actions’lar kullanıyorsa bağımlılıkları ayrıca yönetilmelidir; belgelerde yerel actions bağlantılarını $/ biçimine geçirme seçeneği açıklanıyor.

Dolayısıyla tek bir lockfile kaydı zincirin bir parçası olabilir, ancak zincirin tüm halkalarının denetiminin yerini tutmaz. Harici bir reusable workflow için çağrının sabitlenip sabitlenmediğini ve kaynak deponun durumunu kontrol edin; yerel actions’larda ise bağımlılıklarının nasıl hesaba katıldığını doğrulayın.

CI’ı beklenmedik biçimde durdurmadan denetim nasıl uygulanır?

GitHub, önce seçili depolar ve workflow’lar üzerinde pilot uygulama yapılmasını öneriyor. Require lockfile politikası, uses: bağımlılığı olmayan workflow’lar da dâhil olmak üzere, doğru lockfile bulunmayan hedef workflow’ların çalıştırılmasını engeller. Politikalar için Evaluate modu yalnızca GitHub Enterprise Cloud’da kullanılabilir. Bu nedenle zorunlu kuralı etkinleştirmeden önce kapsamı ve otomatik güncelleme sürecini hazırlayın.

1. Başlangıç bağlantılarını denetleyin. Lockfile oluşturmadan önce actions’ların, ekibin gerçekten sabitlemek istediği sürümlere işaret ettiğinden emin olun. Oluşturucu, mevcut bağlantının çözümlendiği commit’i sabitler.
2. Lockfile’ı oluşturun ve inceleyin. gh-actions-lock uzantısını yükleyin, deponun kök dizininden gh actions-lock komutunu çalıştırın ve yeniden yazılan uses bağlantıları dâhil tüm diff’i inceleyin.
3. Güncelleme ve doğrulamayı ayarlayın. Dependabot, önceden yapılandırılmış workflow’lar için ilgili kayıtları güncelleyebilir. CI’daki pull request denetim görevini gh actions-lock --verify ile yapılandırarak ana derlemeden önce güncelliğini yitirmiş lockfile’ları tespit edebilirsiniz.
4. İnceleyenleri belirleyin. .github/workflows/actions.lock dosyasını CODEOWNERS’a ekleyin ve derleme güvenliğinden sorumlu kişilerin değişiklikleri incelemesini zorunlu kılın.
5. Politikayı pilot olarak uygulayın. Bağlı depolar ve workflow’larla başlayın. Evaluate modunda sonuçları inceleyin; Active moduna geçmeden önce tüm hedef workflow’ların hazır olduğunu ve lockfile’ların güncel kaldığını doğrulayın.

Require lockfile ile ayrı bir kural olan Require actions to be pinned to a full-length commit SHA farklı politikalardır; GitHub, ikisinin birlikte kullanılabileceğini belirtiyor. CI doğrulaması ve zorunlu politika da farklı roller üstlenir: ilki pull request üzerinde çalışırken eski dosyaları tespit eder, ikincisi gerekliliğe uymayan workflow’ların çalıştırılmasını engeller.

Örnek: deployment action’ını güncelleme

Bir workflow’un uygulamayı octo-org/deploy-action@v3 üzerinden yayımladığını varsayalım. Ekip önce bu bağlantının hangi sürüme çözümlendiğini kontrol eder, ardından gh actions-lock komutunu çalıştırır ve workflow diff’ini lockfile’daki commit kaydıyla birlikte inceler. Action güncellendiğinde inceleyen kişi bağlantılardaki ve sabitlenen commit’teki değişiklikleri görür; böylece hareketli etiketin hep aynı kodu göstereceğini varsaymak yerine belirli güncellemeyi değerlendirebilir.

Deployment başka bir depodaki reusable workflow tarafından gerçekleştiriliyorsa yerel lockfile bu workflow’un bağımlılıklarını kapsamaz. Reusable workflow bağlantısını tam SHA ile sabitleyin ve kaynak deponun kendi action bağımlılıklarını yönettiğini doğrulayın. Büyük kuruluşlarda bu yaklaşım, parametreler, sırlar ve runner için ayrı denetimi korurken dağınık kuralları denetlenebilir bir sürece dönüştürür.

Lockfile, action kodunu denetlemenin yararlı bir katmanıdır: geçişli bağımlılıklar dâhil sürümleri ve güncellemeleri görünür kılar. Kapsamı güvenilir hâle getirmek için reusable workflow’ları ve yerel actions’ları da denetleyin, güncellemeleri otomatikleştirin ve zorunlu politikayı ancak pilot uygulamadan sonra başlatın.