GitHub rulesets sa zapnú hneď: migrácia môže zablokovať prvý merge

Ochranu vetvy preneste na GitHub rulesets až po zaznamenaní pôvodných nastavení a kontrole náhľadu konverzie. Postup konverzie v GitHub Enterprise Cloud uvádza, že predvolený stav Active začne pravidlá vynucovať hneď po vytvorení rulesetu. Ak nový súbor podmienok obsahuje požiadavku, ktorú otvorený pull request nespĺňa, prvé zlúčenie sa môže zastaviť.

Pôvodné pravidlo preto pri konverzii ponechajte a výsledok overte pred jeho odstránením. V GitHub Enterprise Cloud možno namiesto predvoleného Active zvoliť Evaluate: nový ruleset potom zaznamenáva, ako by sa správal, ale ešte neblokuje zmeny. Táto možnosť pomáha pri porovnaní pravidiel; skutočné vynucovanie treba preveriť po prepnutí na Active.

Uložte si stav, ku ktorému sa môžete vrátiť

Pred zmenou vytvorte vlastný export nastavení, napríklad internú tabuľku alebo konfiguračný záznam. Zachyťte názov ochranného pravidla, vzor cieľových vetiev, počet požadovaných schválení, kontrolu vlastníkov kódu, rušenie starších schválení a povinné kontroly CI vrátane ich presných názvov a očakávaných zdrojov. Pridajte požiadavky na podpisy, nasadenia, riešenie diskusií a osoby či aplikácie s výnimkou. Ide o váš pracovný záznam, nie o automatický export, ktorý by vytvoril sprievodca konverziou.

Zaznamenajte aj stav otvoreného pull requestu smerujúceho do chránenej vetvy: ktoré kontroly už prešli, kto schválil zmenu a či ostala nevyriešená diskusia. Pri porovnaní po konverzii tak odlíšite novú prekážku od podmienky, ktorá chýbala už pred ňou. Ak sa pravidlo vzťahuje na viac vetiev, poznačte si konkrétne názvy, na ktorých má ochrana platiť.

Pred vytvorením ďalšieho pravidla zistite, ktoré rulesets už na cieľovú vetvu dopadajú. Vysvetlenie súbehu pravidiel GitHubu uvádza, že rulesets a ochrana vetvy sa uplatňujú spoločne; pri rôznych verziách tej istej požiadavky platí prísnejšia. Ponechanie pôvodnej ochrany teda zachová bezpečnostnú poistku, no samo osebe nezaručí, že tím bude môcť zlučovať zmeny rovnakým spôsobom.

Vyskúšajte pravidlá na vedľajšej vetve

Na skúšku vytvorte samostatnú cieľovú vetvu a dočasný ruleset zacielený iba na ňu. Nastavte v ňom požiadavky, ktoré plánujete po konverzii používať, a otvorte pull request do tejto vetvy. Ak pôvodná ochrana cieli presne na hlavnú vetvu, vedľajšia vetva ju automaticky nezdedí. Skúšku preto berte ako overenie zamýšľaných podmienok, nie ako dôkaz, že obe vetvy majú totožnú konfiguráciu.

Prejdite povolený aj zamietnutý priebeh. Pri pull requeste so splnenými podmienkami sledujte, či je zlúčenie dostupné. Potom oddelene skúste chýbajúce schválenie, neúspešnú povinnú kontrolu a nevyriešenú diskusiu. Ak vaša politika vyžaduje nasadenie, podpísané commity alebo výsledok bezpečnostného skenovania, pripravte aj prípad bez príslušného úspešného výsledku. Pri každom pokuse si poznačte konkrétnu požiadavku, ktorú GitHub vyhodnotil.

Samostatne preverujte výnimky pre správcov, tímy a GitHub Apps. Účet, ktorý má pravidlo obísť, skúšajte iba tam, kde je taká výnimka zámerná; bežný účet musí byť naďalej blokovaný pri nesplnenej požiadavke. Ak CI workflow beží len pre vybrané vetvy alebo nasadenie používa iné prostredie, výsledok skúšky na vedľajšej vetve nemusí zodpovedať produkčnému pull requestu. Také rozdiely si označte na kontrolu priamo na skutočnej cieľovej vetve.

Pri konverzii skontrolujte náhľad a stav vynucovania

V repozitári otvorte Settings, potom Branches a pri príslušnom Branch protection rule vyberte Convert to ruleset. Pomenujte každý vznikajúci ruleset a prejdite časť New behavior, ktorá ukazuje zmenu správania pred vytvorením. Z jedného ochranného pravidla môže vzniknúť viac rulesets; pri každom skontrolujte cielenie na vetvy, požiadavky aj výnimky. Samotné potvrdenie sprievodcu ešte nie je overením výsledku.

Voľbu Delete branch protection rule once migration is done nechajte vypnutú. Ak máte pri konverzii dostupný stav Evaluate, najprv v ňom vyhodnoťte rozdiely a až potom prepnite ruleset na Active. Pri predvolenom Active počítajte s okamžitým vynucovaním a pripravte si čas na kontrolu prvého pull requestu. Ponechané pôvodné pravidlo bude na zodpovedajúce vetvy platiť súčasne s novým rulesetom.

Skontrolujte podmienky, ktoré sa ľahko prehliadnu

Prehľad dostupných pravidiel GitHub rulesets zahŕňa schválenia, povinné kontroly stavu, úspešné nasadenie do určeného prostredia, overené podpisy commitov aj výsledky code scanningu. Požiadavku na vyriešenie diskusií skontrolujte osobitne. V pôvodnej ochrane vetvy stojí samostatne, zatiaľ čo v rulesete patrí pod pravidlo vyžadujúce pull request a uplatní sa len vtedy, keď je toto pravidlo zapnuté.

Pri kontrolách CI porovnajte presný názov kontroly, prípadný určený zdroj výsledku a nastavenie, či musí byť vetva pred zlúčením aktuálna voči cieľovej vetve. Ak ruleset očakáva výsledok od konkrétnej GitHub App a kontrolu odošle iný zdroj, zlúčenie nebude povolené. Pri nasadení overte, že zvolené prostredie zodpovedá tomu, do ktorého sa zmeny pred zlúčením skutočne nasadzujú.

Podpisy skúšajte so spôsobom zlúčenia, ktorý tím používa. GitHub pri posudzovaní pull requestu preveruje aj commity z jeho vetvy; nepodpísaný commit môže zablokovať dokonca aj squash merge. Pri požiadavke na code scanning môže zlúčenie zastaviť nález určenej závažnosti, prebiehajúca analýza alebo chýbajúca konfigurácia požadovaného nástroja. Tieto podmienky nepridávajte iba preto, že ich ruleset ponúka: každá z nich mení cestu, ktorou sa zmena dostane do chránenej vetvy.

Overte prvé zlúčenie a zachovajte možnosť návratu

Po aktivácii použite nízkorizikový pull request do skutočnej chránenej vetvy. Porovnajte jeho stav zlúčenia s pôvodným záznamom: schválenia, diskusie, CI, podpisy, nasadenie a skenovanie majú zodpovedať zamýšľanej politike. Overte aj účet alebo aplikáciu s oprávnenou výnimkou, ak sa na tento proces spolieha automatizácia. Prvé zlúčenie vykonajte bežným postupom až po splnení požiadaviek; obídenie pravidla by jeho správanie nepreverilo.

Pri nečakanom blokovaní určte ruleset a konkrétnu nesplnenú podmienku. Opravte chybné cielenie, názov kontroly, zdroj výsledku alebo výnimku a pokus zopakujte. Ak opravu nemožno urobiť hneď, zmeňte stav nového rulesetu na Disabled; ponechaná pôvodná ochrana bude ďalej platiť pre vetvy, na ktoré sa vzťahuje. Pôvodné pravidlo odstráňte až po úspešnom overení aktívneho rulesetu na skutočnej cieľovej vetve.

Prečítajte si aj:

• SPF, DKIM a DMARC: druhý SPF záznam môže ochranu domény pokaziť
• GitHub či GitLab: lacnejšie konto môže prehrať na minútach CI
• XTB či Interactive Brokers: nulová komisia môže prehrať na konverzii