Flyt branch protection til GitHub Rulesets – overlap kan blokere merges

Registrér kravene i den eksisterende branch protection, konvertér reglen til GitHub Rulesets, og behold den gamle regel, mens I afprøver en pull request. GitHubs konverteringsvejledning beskriver, at et nyt aktivt ruleset håndhæves sammen med den bevarede regel: ændringer skal opfylde begge, før de kan merges.

Den rækkefølge bevarer beskyttelsen under overgangen, men kan også gøre en merge vanskeligere end forventet. Gennemgå derfor den nye adfærd før oprettelsen, afprøv status checks og bypass-adgange, og fjern først den gamle regel, når en almindelig prøve-pull request er merget med de forventede krav opfyldt.

Før konverteringen: registrér de krav, der gælder

Find den branch protection-regel, der beskytter målgrenen, og skriv dens målretning og krav ned. Medtag godkendelser, code owners, løste samtaler, krævede status checks, krav om at være ajour med basisgrenen og begrænsninger for push og merge. Notér også, hvilke roller, teams og apps der har særlige adgange; de skal gennemgås særskilt i den nye konfiguration.

Brug en eksisterende pull request som sammenligningsgrundlag. Registrér, hvilke checks der normalt vises, hvilke godkendelser der kræves, og hvilken merge-metode teamet bruger. Vælg derefter en lille ændring, der egner sig til en prøve-merge. Hvis GitHub senere afviser den, kan I sammenholde den konkrete blokering med den tidligere adfærd.

Se samtidig efter aktive rulesets, som allerede rammer målgrenen, også hvis de er oprettet uden for repositoryets egne indstillinger. Ellers kan et krav fra et eksisterende ruleset blive forvekslet med en ændring skabt af konverteringen. Notér hvert relevant rulesets målretning og undtagelser sammen med den gamle regel.

Under konverteringen: behold branch protection

Åbn repositoryets Settings og derefter Branches. Find reglen under Branch protection rules, vælg Convert to ruleset, og giv de foreslåede rulesets navne. Læs feltet New behavior, før I vælger Create ruleset. Lad Delete branch protection rule once migration is done være fravalgt, så den eksisterende beskyttelse bliver liggende, mens I afprøver resultatet.

Sammenhold forhåndsvisningen med den oprindelige kravliste, især hvis konverteringen opretter flere rulesets. Kravet om løste samtaler fortjener særskilt kontrol: I branch protection er det en selvstændig indstilling, mens det i Rulesets hører under reglen om pull requests og kun gælder, når den regel er slået til. Kontrollér derfor både pull request-reglen og dens indstilling for samtaler i stedet for at antage, at kravet er flyttet uændret.

Undersøg også, hvilke branches hvert nyt ruleset rammer. Hvis målretningen er bredere end den gamle regels, kan andre pull requests få nye krav; hvis den er snævrere, kan en branch stadig være beskyttet alene af den gamle regel. Ret afvigelser, som I ikke bevidst ønsker, før prøven begynder.

Overlappende regler: find hele årsagen til en blokering

Rulesets har ingen indbyrdes prioritet. GitHubs forklaring af reglers lagdeling beskriver, at regler for samme branch lægges sammen med branch protection, og at den mest restriktive udgave gælder, når samme krav er sat forskelligt. En pull request kan derfor være blokeret af et andet aktivt ruleset end det, I netop har oprettet.

Som et tænkt eksempel kan den gamle regel kræve én godkendelse, mens et andet ruleset kræver to. Det strengere krav gælder stadig efter konverteringen. Sammenhold derfor merge-beskeden med alle regler, der rammer grenen, før I ændrer godkendelser eller slår et ruleset fra for at få en enkelt pull request igennem.

Gennemgå bypass pr. relevant regel. En rolle eller app, som må omgå et nyt ruleset, er ikke dermed undtaget fra alle andre krav, der beskytter branchen. Afprøv først merge som en almindelig bidragyder uden bypass; kontrollér derefter særskilt de undtagelser, teamet faktisk bruger. En merge gennem en undtagelse viser ikke, at den normale vej fungerer.

Prøv status checks og en almindelig merge

Kontrollér navnene på de krævede checks på prøve-pull requesten og se, hvilken kilde der leverer dem. GitHubs oversigt over ruleset-regler fastslår, at alle krævede status checks skal bestå før merge. Hvis et check er knyttet til en bestemt GitHub App som forventet kilde, kan en status fra en anden afsender ikke opfylde kravet.

Kontrollér derefter Require branches to be up to date before merging. Med den stramme indstilling skal pull request-grenen være ajour med basisgrenen. Når andre ændringer lander først, kan en opdatering af grenen kræve flere builds. Den løse indstilling undgår dette krav, men en merge kan da efterfølges af fejlede tests, hvis ændringerne ikke fungerer sammen med den nyere basisgren. Vælg den adfærd, I faktisk ønsker at håndhæve.

Gennemfør prøve-pull requesten med de normale godkendelser, checks og merge-rettigheder. Hvis den blokeres, så identificér det konkrete manglende check, review eller branch-krav og ret enten pull requesten eller konfigurationen, mens den gamle beskyttelse stadig gælder. Prøv igen uden bypass, så resultatet afspejler teamets almindelige arbejdsgang.

Efter prøven: fjern den gamle regel og kontrollér resultatet

Når en almindelig prøve-pull request er merget, skal I sammenholde det nye ruleset med den oprindelige kravliste endnu en gang. GitHub kan på siden Branches vise, at den gamle regel er fuldt dækket af rulesets, og tilbyde Delete. Brug først sletningen, når målretning, samtaler, checks og relevante adgange også svarer til den ønskede beskyttelse.

Opret derefter en ny pull request mod samme branch og kontrollér dens merge-krav. Den første prøve viste, at gammel og ny beskyttelse kunne fungere sammen; denne kontrol viser, hvordan repositoryet fungerer med det nye ruleset alene. Hvis et forventet krav mangler eller en merge stadig blokeres, så brug den oprindelige kravliste til at rette det relevante ruleset.

Læs også:

• Kina matcher flere danske eksportstyrker – overlap er steget til 48 pct.
• WCAG-test: En automatisk scanner kan ikke godkende dit website alene
• DMARC uden mailnedbrud: Gå fra p=none til p=reject i trin