GitHub Rulesetsre váltás: a régi védelem aktív maradhat

A meglévő GitHub branch protection szabályokat egyenként alakítsd át Rulesetsre, és a régi szabályt csak az új védelem ellenőrzése után töröld. A GitHub átalakítási útmutatója szerint a létrehozott ruleset Active állapotban lép életbe; ha megtartod a korábbi szabályt, az is védi az érintett ágakat, így a módosításoknak mindkét védelemnek meg kell felelniük.

Az átállás sorrendje ezért leltár, beállításonkénti összevetés, átalakítás, majd próba a régi szabály törlése előtt és után. A pull requestek beszélgetéseinek feloldását külön kezeld: ez a feltétel a két szabálytípusban eltérő helyen szerepel, ezért az automatikus átalakítás eredményéből önmagában nem következtethetsz a működésére.

Leltár: melyik ágat mi védi?

A leltár alapja a célág legyen, ne csupán a szabály neve. Írd fel az alapértelmezett ágat, a kiadási ágakat és a használt ágmintákat, majd minden célághoz rendeld hozzá a rá illeszkedő régi védelmet. Ha szervezeti vagy repositoryszintű ruleset is vonatkozik rá, azt külön sorban jelöld: az átalakítás eredményét csak a teljes szabálykörnyezetben lehet megítélni.

Rögzítsd a pull requesthez kötött feltételeket: szükséges jóváhagyások, code owner jóváhagyás, kötelező státuszellenőrzések, telepítés és feloldott beszélgetések.
Jegyezd fel az ágra közvetlenül küldött módosítások, a force push és az ágtörlés korlátozásait, valamint az aláírt commitokra és a lineáris előzményekre vonatkozó elvárásokat.
Írd mellé az érintett szerepköröket, a megkerülési jogosultságokat és azokat a GitHub Appokat vagy botokat, amelyek az ágat módosítják.

Ebből készíts beállítástérképet: célág vagy ágminta, jelenlegi feltétel, tervezett rulesetbeli megfelelője és a hozzá tartozó próba kerüljön egymás mellé. Egy kötelező ellenőrzésnél például azt érdemes felírni, hogy a sikeres és a hiányzó ellenőrzés mellett milyen merge állapotot vársz. Így a későbbi blokkolást konkrét követelményhez tudod kötni, nem kell a ruleset nevéből találgatnod.

Az átalakítás lépései

Egyszerre egy branch protection szabállyal haladj. Az átalakító egy korábbi szabályból több rulesetet is létrehozhat, ezért a folyamatban megjelenő minden új szabálykészlet nevét és várható működését külön vesd össze a leltárral. Az átalakításhoz repositoryadminisztrátori hozzáférés vagy az „edit repository rules” jogosultságot tartalmazó egyéni szerepkör szükséges.

A repository oldalán nyisd meg a Settings menüt, majd a Branches részt.
A Branch protection rules listában keresd meg az átalakítandó szabályt, és válaszd a Convert to ruleset műveletet.
Adj nevet minden létrejövő rulesetnek. A New behavior résznél nézd át, hogyan változnak a célágak és a követelmények.
Hagyd üresen a Delete branch protection rule once migration is done jelölőt, ha a régi szabályt a próbák idejére megtartod, majd válaszd a Create ruleset gombot.

A létrehozás után nézd meg a célzott ágakat és a ténylegesen beállított feltételeket. A hasonló név nem bizonyítja, hogy a ruleset ugyanazt az ágmintát, ellenőrzést vagy jogosultsági kört érinti. Ha az előnézet eltérést mutatott, annak hatását még a régi szabály törlése előtt tisztázd.

Mit okoz a párhuzamos védelem?

Az új ruleset nem váltja fel hallgatólagosan a megtartott branch protection szabályt. A GitHub szabályrétegzési leírása szerint ugyanarra az ágra több ruleset is vonatkozhat, míg a hagyományos ágvédelmi szabályok közül egyszerre egy érvényesül; az alkalmazandó követelmények összeadódnak. Ha ugyanazt a feltételt eltérő szigorral adják meg, a szigorúbb változat érvényesül.

Egy váratlanul blokkolt pull requestnél ezért a célág összes aktív szabályát nézd meg. Feltételes példa: az új ruleset jóváhagyást kér, a megtartott régi szabály pedig kötelező státuszellenőrzést is előír. Amíg az ellenőrzés nem sikeres, a jóváhagyott pull request sem egyesíthető.

A fordított helyzet ugyanilyen fontos a próbánál. Ha egy műveletet a régi szabály blokkol, abból még nem derül ki, hogy az új ruleset is blokkolná-e. A törlés előtti próba a két réteg együttes működését mutatja; az új szabály önálló hatása a régi védelem eltávolítása után ítélhető meg.

A beszélgetések feloldását külön állítsd be

A Require conversation resolution before merging beállítás nem vihető át egy az egyben. A régi ágvédelemben önálló feltétel, a rulesetben viszont a pull requestet megkövetelő szabály része, és csak annak bekapcsolásakor alkalmazható. A GitHub pull request szabályainál külön választható, hogy az összes hozzászólást fel kelljen oldani az egyesítés előtt.

Ha a régi szabály megkövetelte a feloldást, ellenőrizd, hogy az új rulesetben aktív-e a pull request feltétel, és azon belül szerepel-e a beszélgetések feloldása. Készíts vagy használj egy próba pull requestet feloldatlan beszélgetéssel. A régi szabály megtartása mellett tapasztalt tiltás még nem bizonyítja, hogy a rulesetben is helyesen állítottad be ezt a kivételt.

Próba a törlés előtt és után

A próbát olyan szerepkörrel végezd, amely a szokásos fejlesztői folyamatban vesz részt, és nem rendelkezik megkerülési joggal. Először egy minden feltételt teljesítő pull requestet nézz meg, majd olyan változatokat, amelyekből egy-egy kötelező elem hiányzik. A várt eredményt mindig a leltár adott célágához és szerepköréhez mérd.

Ha kötelező a jóváhagyás vagy a státuszellenőrzés, nézd meg külön a hiányzó jóváhagyás, illetve a még futó vagy sikertelen ellenőrzés hatását.
Az érintett ágon ellenőrizd a feloldatlan beszélgetést, majd annak feloldása után a többi feltétel mellett kialakuló merge állapotot.
Ha a védelem közvetlen pushra vagy force pushra is vonatkozik, erre alkalmas próbaágon vizsgáld a tiltást az érintett szerepkörrel.
Vesd össze az eredményeket a célágra illeszkedő többi aktív repository- és szervezeti rulesettel.

Ha az új beállítások készen állnak, térj vissza a Branches oldalra, és töröld a régi branch protection szabályt. A felület Delete gombot és a teljes rulesetbeli lefedettségről szóló jelzést mutathat, de a beszélgetésfeloldás külön beállítását és a várt működést ettől függetlenül ellenőrizd. A törlés után ismételd meg legalább azt a blokkoló próbát, amelyet korábban a régi szabály is teljesíthetett, különösen a feloldatlan beszélgetéssel: ekkor látszik, hogy a kívánt korlátot már az új szabálykészlet tartja fenn.

Olvassa el ezt is: