Dependabot groeperen zonder beveiligingsfixes te missen

Met groepsregels in .github/dependabot.yml kun je routineupdates van Dependabot bundelen en beveiligingsupdates apart houden. De Dependabot-configuratiereferentie beschrijft hoe passende updates in één pullrequest komen en updates buiten een groep afzonderlijk verschijnen. Groepeer daarom op het risico dat je samen wilt beoordelen, niet alleen op pakketbeheerder.

Een bruikbare indeling is: productiepatches samen, patch- en minor-updates van ontwikkeldependencies samen, en een eigen beveiligingsgroep voor kleine fixes in ontwikkeldependencies. Productiebeveiligingsupdates, major-updates en bewust uitgezonderde pakketten blijven buiten die groepen. Zo daalt het aantal routinepullrequests zonder dat verschillende soorten wijzigingen vanzelf in dezelfde review belanden.

Kies eerst het juiste manifest en pakkettype

Het voorbeeld hieronder gaat uit van een npm-project met zijn manifest in de hoofdmap van de repository. Daarom staat directory op '/'. Staat package.json in een submap, vervang dit pad door de locatie van dat manifest. Voor een ander pakketecosysteem is een eigen updates-item nodig; neem de indeling production en development alleen over als dat ecosysteem en zijn manifesten die indeling ondersteunen.

In de configuratie bepaalt schedule: {interval: weekly} wanneer Dependabot naar gewone versie-updates zoekt. Die wekelijkse instelling is geen reden om beveiligingsfixes tot de volgende onderhoudsronde te laten wachten. De groepsregels maken juist zichtbaar welk soort update in welke pullrequest thuishoort.

Gebruik drie begrensde YAML-groepen

De volgende compacte flow-notatie is één volledige YAML-configuratie. Plaats haar in .github/dependabot.yml en pas de manifestlocatie en pakketuitzondering aan je repository aan. react is hier uitsluitend een voorwaardelijk voorbeeld van een pakket dat je afzonderlijk wilt beoordelen.

{version: 2, updates: [{package-ecosystem: npm, directory: '/', schedule: {interval: weekly}, groups: {productie-patches: {applies-to: version-updates, dependency-type: production, update-types: [patch], patterns: ['*'], exclude-patterns: [react]}, ontwikkel-updates: {applies-to: version-updates, dependency-type: development, update-types: [minor, patch], patterns: ['*']}, security-ontwikkeling: {applies-to: security-updates, dependency-type: development, update-types: [minor, patch], patterns: ['*']}}}]}

productie-patches combineert uitsluitend passende patch-updates van productiedependencies. ontwikkel-updates neemt patch- en minor-updates van ontwikkeldependencies mee. Beide zijn gewone versie-updates. De expliciete applies-to-waarden maken dat onderscheid leesbaar; zonder deze sleutel geldt een groep standaard voor versie-updates.

security-ontwikkeling is een afzonderlijke groep voor beveiligingsupdates van ontwikkeldependencies die binnen patch of minor vallen. De gekozen grens houdt productiebeveiligingsupdates en major-beveiligingsupdates erbuiten. Een kwetsbaarheid kan best een grotere versiestap vereisen; zo’n update verdient dan een eigen beoordeling in plaats van een verruiming van de routinegroep.

Zorg dat de beveiligingsroute werkelijk actief is

Voor gegroepeerde beveiligingsupdates moeten de dependency graph, Dependabot alerts en Dependabot security updates aanstaan. GitHubs instructie voor beveiligingsupdates beschrijft ook de expliciete sleutel applies-to: security-updates, een manifestpad dat naar de juiste locatie verwijst en het weglaten van target-branch. Beveiligingspullrequests richten zich op de standaardbranch; met target-branch zouden de instellingen voor dit pakketecosysteem alleen op versie-updates van toepassing zijn.

Controleer daarnaast de instelling voor gegroepeerde beveiligingsupdates op repository- of organisatieniveau. YAML-regels bepalen de groepering voor de geconfigureerde directories; een algemene instelling kan nog groeperen in directories die buiten die configuratie vallen. Wie productiebeveiligingsfixes afzonderlijk wil zien, moet dus ook nagaan welke manifestlocaties de configuratie daadwerkelijk dekt.

Een beveiligingsgroep is een keuze voor gezamenlijke beoordeling, geen aanduiding van urgentie. Wijs een reviewer aan die de meldingen volgt, en beoordeel een fix op de geraakte dependency en de wijziging die nodig is. Laat een productiebeveiligingsupdate niet wachten omdat de ontwikkelgroep een overzichtelijker pullrequest oplevert.

Houd major-updates en kritieke pakketten buiten de routinegroepen

De update-types in het voorbeeld sluiten major-versie-updates uit van beide gewone groepen. Dat geeft ruimte om per pakket migratie-instructies, gewijzigde API’s en gevolgen voor de applicatie te bekijken. Een brede regel met patterns: ['*'] zonder update-types zou ook zulke updates kunnen verzamelen en daarmee de omvang van één review veranderen.

Met exclude-patterns blijft het voorwaardelijke pakket react buiten de groep voor productiepatches. Staat het pakket ook niet in een andere passende groep, dan krijgt de update een eigen pullrequest. Vervang react door de exacte naam van een dependency die in jouw project extra aandacht vraagt, of verwijder de uitzondering. Een pakket uitsluiten van een groep is iets anders dan zijn updates met ignore onderdrukken.

De volgorde van regels verdient aandacht zodra groepen elkaar overlappen: een update gaat naar de eerste passende groep. Houd groepsgrenzen daarom expliciet en controleer ze opnieuw wanneer je later een brede regel toevoegt. Anders kan een pakket dat je afzonderlijk wilde beoordelen alsnog in een nieuwe verzamelgroep belanden.

Controleer de eerste pullrequests en de mergevoorwaarden

Na het toevoegen van de configuratie laten de eerste pullrequests zien of de manifestlocatie en groepsgrenzen overeenkomen met de bedoeling. Controleer de volledige wijziging in een groepspullrequest: meerdere dependency-updates kunnen samen een ander testresultaat geven dan elk afzonderlijk. Laat CI daarom de dependencies installeren en de relevante tests en build uitvoeren op die gezamenlijke wijziging.

Voor de doelbranch kun je met branch protection in GitHub geslaagde statuschecks en goedkeuring verplicht stellen voordat een pullrequest wordt gemerged. Kies vereiste checks die ook daadwerkelijk op Dependabot-pullrequests draaien, en bepaal welke groepen menselijke goedkeuring nodig hebben.

Controleer of productiepatches en ontwikkelupdates in hun bedoelde groepen terechtkomen.
Controleer of de uitgezonderde dependency, major-updates en productiebeveiligingsfixes afzonderlijk zichtbaar zijn.
Controleer of CI op de volledige groepspullrequest draait en de vereiste checks een merge blokkeren bij falen.
Controleer of beveiligingsmeldingen en pullrequests bij de verantwoordelijke reviewers terechtkomen.

Verruim een groep pas als de eerste wijzigingen samen goed te testen en te beoordelen blijken. Het aantal pullrequests is daarbij een nuttige maat voor onderhoudslast, maar de inhoud van elke review bepaalt of de groepering werkt.