Tamamlanmış görünen bir Dependabot config'i altı güncellenebilir yüzeyden yalnızca ikisini izliyordu

Bitmiş gibi okunan bir config

Kurulum su geçirmez görünüyordu: pip ve github-actions olmak üzere iki girdili bir dependabot.yml, her ikisi de repository kökünü hedefliyor ve her ikisi de haftalık programda. Juan Auriti'nin dev.to'daki yazısına göre bu dosya, CI'lı bir Python projesine hizmet ediyordu ve alelacele bir okumayla eksiksiz görünüyordu.

Sonra yazar, bir dependency bot'un repository içinde gerçekte dokunabileceği her şeyi envanterledi. Liste şunlardan oluşuyordu: pyproject.toml, frontend/package., integrations/astro-geoready/ altında ikinci bir package., kökte iki Dockerfile, kökte bir action.yml, .github/actions/geo-audit/ içinde bir composite action ve altı workflow dosyası. Altı ayrı güncelleme yüzeyi vardı. Config bunlardan ikisini izliyordu.

Her boşluğun neden görünmez olduğu

npm boşluğu en basit kaçırma: Dependabot dizin bazında çalışır ve config'de hiçbir yerde npm girdisi yoktu; böylece tüm bir frontend dependency'si izlenmeden kaldı. Yazının belirttiği incelik şu: /frontend için tek bir npm girdisi bile ikinci package.'yı kapsamazdı; çünkü manifest içeren her dizinin kendi girdisine ihtiyacı vardır ve iç içe entegrasyon paketi, config yazarın aklındaki dizin için yazılırken unutulmuştu.

Dockerfile'lar daha basit bir nedenle atlanmıştı: docker ekosistem girdisi yoktu, dolayısıyla base image etiketleri hiç güncellenmiyordu. Her iki dosya da repository kökünde olduğu için tek bir girdi onları kapsayabilirdi — ama sıfır girdi ikisini de kapsıyordu.

En öğretici boşluk composite action'dı. Yazının açıkladığı gibi, directory'si / olan bir github-actions girdisi .github/workflows altındaki workflow dosyalarını ve kökteki action.yml'yi kapsar ama kendi alt dizininde yaşayan bir composite action'a ulaşmaz. O iç içe dosya, her workflow gibi üçüncü taraf action'ları sabitler ve .github/ içindeki konumu, yazarın zaten kapsandığını varsaymasının tam da nedenidir.

İki komutluk bir denetim

Yazı, her repository'de işe yarayan bir uzlaştırma alıştırması öneriyor: ilk komut, node_modules, .venv ve dist dizinlerini budarak vendored manifest'lerin çıktıyı boğmasını engellerken, güncellenebilir her manifest'i listeliyor — package., requirements dosyaları, pyproject.toml, Gemfile, go.mod, Cargo.toml, Dockerfile'lar ve action dosyaları; ikinci komut dependab.yml içinden package-ecosystem ve directory satırlarını grep'liyor. İki listeyi gözle karşılaştırmak farkı ortaya çıkarır.

Yazar ayrıca bir listenin diğerine karşı okunması için gereken eşlemeyi de veriyor: pip, pyproject.toml veya requirements dosyalarını tutan dizini izler; npm ve docker da tıpkı bunun gibi dizin bazında çalışır; workflow'lar kökteki bir github-actions girdisiyle kapsanır; ve neredeyse hiç kimsenin yazmadığı durum olarak, iç içe bir action.yml, action'ın kendi dizinini gösteren ayrı bir github-actions girdisine ihtiyaç duyar.

Kapatılan pull request'ler geri gelmez

Yapılandırmayı düzeltirken yazar, aylar öncesinden kalmış bayat pull request'ler buldu ve birkaçını, daha sonraki bir minor sürümün çoktan geçtiği bir patch bump dahil, geçersiz kılındıkları için kapattı. Bu, yazıdaki ikinci uyarıyı tetikledi: Dependabot kapattığınız bir pull request'i yeniden açmaz ve reddettiğiniz bir sürümü yeniden önermez. Eski PR gibi görünen şeyi kapatmak, o güncelleme hakkında bir karar kaydeder. Yerine geçen PR gerçekten açık değilse, dependency artık süresiz olarak mevcut sürümünde kalır; açık bir PR de, hata da yoktur.

Pratik öneri, geçersiz kılınan bir PR'ı ancak yerine geçenin mevcut ve açık olduğunu doğruladıktan sonra kapatmaktır. Ve dependabot.yml kapanışlar hakkında hiçbir şey kaydetmediği için, tek görünür belirti PR üretmeyi bırakan bir dependency'dir — bu da tamamen güncel bir dependency ile birebir aynı görünür.

Neden önemli

Yazının çerçevelediği temel sorun şu: dependabot.yml neyi izlemesini istediğinizi anlatır ama hiçbir yerde neyi istemeniz gerektiğini anlatan bir şey yoktur. GitHub izlenmeyen bir manifest için uyarı vermez ve bir ekosistem eklemek dizin bazında tercihli olduğundan, dosya yazarken aklınızda olan ekosistemleri kapsadığı anda bitmiş gibi okunur.

Daha geniş ders Dependabot'un çok ötesine genellenir: bir izin listesinin hata durumu yoktur. Onu gözden geçirmek her zaman doğru olduğunu doğrular, çünkü tam olarak listelediği şeyi listeler. Tek güvenilir denetim dışarıdan gelir — config'in kapsaması gereken manifest setinin tamamını sayıp config'i ona göre kontrol etmekten. Otomatik dependency güncellemelerini bir güvenlik kontrolü olarak gören ekipler için, eksiksiz görünen bir config dependency yüzeyin sessizce küçük bir bölümünü izliyor olabilir ve bayat PR'lar çevresindeki temizlik alışkanlıkları, iz bırakmadan kalan güncellemeleri dondurabilir.