Actions lockfile genel kullanıma açıldı: yeşil kontrol neyi kanıtlıyor?
PR içindeki uses sürümü aynı görünürken arkasındaki kod değişebilir. Etiketler başka commit’lere taşınabilir. GitHub, workflow lockfile özelliğini 28 Ekim’de genel kullanıma açtı. Önizlemenin ardından her doğrulamanın hangi kanıtı sağladığını anlamak önemli.
Okunabilir başvurular, kayıtlı commit’ler
.github/workflows/actions.lock action başvurularını çalıştırılacak commit’lerle eşleştirir. gh actions-lock ile üretilir; Free, Team ve veri yerleşimi dahil GitHub Enterprise Cloud’da sunulur. Workflow’lar tek tek eklenebilir. Dosyayı elle kurmak yerine üretilen sonuç workflow değişikliğiyle birlikte incelenir.
Varsayımsal demo/build@v1 önce A’ya, sonra B’ye işaret etsin. Yalnızca başvuruyu çözmek sonraki çalışmada farklı kod seçebilir; lockfile kayıtlı commit’i seçer. Görsel gerçek test değil, açıklayıcı örnektir. Commit kayıtlı upstream etiketi veya dalından erişilemez hale gelirse çalışma sırasında reddedilebilir.
Çevrimdışı kontrol neyi doğrular?
gh actions-lock --verify-local ağ kullanmadan uses için kayıt olup olmadığını, yani kapsamı denetler. Commit öncesinde yararlıdır ancak kökeni doğrulamaz. gh actions-lock --verify bunu çevrimiçi yapar; runner iş başında yeniden denetler. İki yeşil sonuç aynı anlama gelmez.
Başka bir PR action ekleyip lockfile güncellemesini unutursa yerel kontrol eksik kaydı bulabilir. Kayıtların tam olması kökeni ya da kod güvenliğini kanıtlamaz. İkinci görsel belgelenen kapsamları özetler; bu yazı için CLI kurulmadı veya çalıştırılmadı.
Yeniden kullanılabilir workflow başka sınır açar
Action’ların geçişli bağımlılıkları kapsanır; jobs.<job_id>.uses çağrıları lockfile ile sabitlenmez. Bunlar tam commit SHA ile belirtilmelidir. İç action’lar çağıran deponun değil workflow’un tanımlandığı deponun lockfile dosyasına bağlıdır.
Bir uygulama deposu platform deposundaki deployment workflow’unu çağırsın. Yalnızca uygulamanın actions.lock dosyasını incelemek platformdaki action sabitlemelerini göstermez. Çağrı SHA’sı ile platform bağımlılıkları birlikte okunmalıdır. Runner imajı, girdiler ve secrets ayrı girdilerdir; action commit’ini sabitlemek tüm ortamı dondurmaz.
Güncelleme PR’ında iki dosyayı birlikte okuyun
Dependabot, sisteme alınmış workflow’daki action sürümünü güncellerken ilgili lockfile kaydını aynı PR’da yeniden üretir. Okunabilir sürüm ve gerçek commit karşılaştırılabilir. --relock taşınan başvuruları ilerletip dosya yazar; salt okunur doğrulamadan farklıdır. Kod incelemesi hâlâ gereklidir.
Require lockfile benimsemeyi zorunlu kılabilir ancak depo sınırlarını kaldırmaz. Tek workflow ile başlamak üretim, inceleme ve çevrimiçi doğrulamayı anlamayı kolaylaştırır. Sonraki yeşil işarette tam olarak hangi kanıtın bulunduğuna bakın: kapsam, köken veya seçilen kodun incelenmesi.