Megjelent a Gitea 28.0, amely fontos mérföldkő a saját üzemeltetésű Git platform számára: a projekt elhagyta a történelmi 1.x előtagot a verziószámokból. Ami korábban Gitea 1.28 volt, az mostantól egyszerűen Gitea 28.

A verziószámozás megváltoztatásán túl az egyik legnagyobb újdonság a beépített audit naplózás. A Gitea mostantól rögzíti a biztonság szempontjából fontos eseményeket, és ezeket az adminisztrációs felületen, a szervezeti, tároló- és felhasználói beállítások között is meg lehet jeleníteni. Az események szűrhetők a végrehajtó (actor), a művelet (action) és az eredet (origin) alapján. Az adminisztrátorok JSONL formátumban exportálhatják az összegyűjtött adatokat. Az audit naplózás alapértelmezés szerint ki van kapcsolva, és 30 napig őrzi meg az eseményeket, hacsak másként nem állítják be.

A Gitea 28.0 dedikált bot fiókokat is bevezet az automatizáláshoz. Ezek a fiókok a normál felhasználóktól eltérően hozzáférési tokenekkel hitelesítenek, nem tudnak interaktívan bejelentkezni, és nem kapnak értesítéseket vagy e-maileket. Az adminisztrátorok a webes felületen, API-n keresztül vagy parancssorból is létrehozhatják és kezelhetik a bot fiókokat.

Hasznos újdonság az adminisztráció számára a felhasználói megszemélyesítés (impersonation) is. Az adminisztrátorok ideiglenesen úgy láthatják a Gitea felületét, ahogyan egy adott felhasználó látja, így könnyebben vizsgálhatják a jogosultsági vagy hozzáférési problémákat anélkül, hogy szükség lenne a felhasználó hitelesítő adataira. Ha az audit naplózás be van kapcsolva, a megszemélyesített munkamenetben végrehajtott műveleteknél mind az adminisztrátor, mind a megszemélyesített fiók rögzítésre kerül.

A tárolók kezelése is több fejlesztést kapott. A Gitea mostantól támogatja a tároló-szintű HTTPS deploy tokeneket, amelyek a csak olvasható vagy írható-olvasható hozzáférést biztosító SSH deploy kulcsok HTTPS-es megfelelői. A branch védelem beállítható úgy, hogy a pull request csak akkor legyen összevonható, ha a megfelelő CODEOWNERS bejegyzések jóváhagyják.

A nagyobb pull requestek átnézése is egyszerűbb lett egy új keresőmezőnek és fájlkiterjesztés-szűrőnek köszönhetően a diff oldalsávban. A szűrés a fájlfára és a megjelenített diffre is vonatkozik. A kiválasztott kiterjesztés-szűrőt az URL tartalmazza, így a nézet könnyen megosztható másokkal.

A Gitea Actions is jelentős fejlesztéseket kapott. Az új build queue megmutatja, mely feladatok futnak, és melyek várnak futtatóra, tároló-szintű és teljes példányra vonatkozó nézettel is. A workflow futások listája automatikusan frissül, a build artefaktumok pedig közvetlenül a böngészőben böngészhetők és előnézetben megtekinthetők, beleértve a szövegfájlokat, képeket, PDF-eket és generált HTML jelentéseket.

Fontos, hogy több, kompatibilitást érintő változás miatt az adminisztrátoroknak át kell nézniük a rendszert verziófrissítés előtt. Mostantól legalább Git 2.25 szükséges, a Gitea nem indul el régebbi verziókkal. Emellett az önregisztráció alapértelmezés szerint ki van kapcsolva, és csak kifejezett engedélyezés után működik. A korábbi [server] DOMAIN beállítást már nem használja a rendszer; a példány domain neve mostantól a ROOT_URL alapján derül ki.

A Git migrációk, tükrözések (mirrorok) és más hálózati műveletek mostantól egy belső proxy-n keresztül futnak, módosított kimenő (egress) szabályokkal. Azoknak a telepítéseknek, amelyek egyedi engedélyezési vagy tiltólistákat használnak, érdemes átnézniük a konfigurációjukat, mielőtt áttérnek a 28.0-s verzióra.

A Gitea Actions futásokra új alapértelmezett megőrzési szabály vonatkozik. A futásokat, jobokat, naplókat és artefaktumokat 400 nap után törli a rendszer, hacsak nem módosítják a RUN_RETENTION_DAYS értékét. Ha ezt 0-ra állítják, az adatok korlátlan ideig megmaradnak.

A valós idejű értesítések mostantól server-sent events helyett WebSocketen keresztül működnek. Azoknak az adminisztrátoroknak, akik Giteát reverse proxy mögött futtatnak, ellenőrizniük kell, hogy a WebSocket upgrade headerek megfelelően továbbítódnak. Ha ez nem teljesül, az értesítésszámláló és az időmérő frissítése visszaáll lekérdezéses (polling) működésre.

További részletekért olvasd el a bejelentést. A projekt azt javasolja, hogy verziófrissítés előtt készíts biztonsági mentést a meglévő adatokról, és nézd át a dokumentált kompatibilitást érintő változásokat.