Gitea, az egyszerűségre és könnyű önhostolásra tervezett, lightweight és nyílt forráskódú Gitea hosting platform kiadta az 1.27-es verziót.

A kiadás egyik fontos változása a többször felhasználható Actions workflow-k jobb kezelése. A uses:-szal hivatkozott workflow-kat mostantól közvetlenül a Gitea dolgozza fel, és az egyes meghívott workflow-kat külön jobokra bontja. Ezek a jobok önálló bejegyzést kapnak a futási sidebarban, külön naplófájl tartozik hozzájuk, és saját csomópontjuk van a függőségi gráfban. Így sokkal könnyebb beazonosítani, hol hibázik egy többször felhasználható workflow.

Támogatottak a beágyazott, többször felhasználható workflow-k is, beleértve a bemenetek, kimenetek és a mátrix jobok továbbadását. Külső, URL-lel egy másik Gitea példányra mutató reusable workflow-kat viszont már nem támogat a rendszer. Azoknak az adminisztrátoroknak, akik eddig erre a megoldásra támaszkodtak, át kell költöztetniük az érintett tárolókat a helyi példányra.

A Gitea Actions mostantól támogatja a job összefoglalókat a GitHub_STEP_SUMMARY környezeti változón keresztül. A workflow lépései Markdown tartalmat írhatnak ebbe a fájlba, amit a Gitea közvetlenül a futás összefoglaló oldalán jelenít meg, nem pedig letölthető artifactként tárol.

Javították a jobs.<job_id>.continue-on-error kezelését is. Korábban a Gitea ugyan feldolgozta ezt a beállítást, de ha az engedélyezett job hibázott, a teljes workflow-t mégis sikertelennek jelölte. Az 1.27-es verzió már helyesen veszi figyelembe ezeket a hibákat a workflow végső állapotának meghatározásakor.

A megszakított workflow-k kezelése is kiszámíthatóbb lett. A Gitea most már képes lefuttatni az utólagos takarító lépéseket és az always() vagy cancelled() feltételeket, mielőtt a jobot megszakítottnak jelöli. A job összefoglalók, az átmeneti „canceling” állapot és a continue-on-error helyes feldolgozása a most megjelent Gitea Runner 2.0-t igényli. A régebbi runnerek továbbra is kompatibilisek, de ezeket az képességeket nem biztosítják.

Ezen felül a szervezetek, felhasználók és adminisztrátorok mostantól egyedi tárolókon kívül is definiálhatnak megosztott Actions workflow-kat. A tulajdonosi szintű workflow-k egy felhasználó vagy szervezet összes tárolója között megoszthatók, míg a globális workflow-k a teljes Gitea példányban elérhetők. Az adminisztrátorok a webes felületen egyszerre több runnert is engedélyezhetnek, letilthatnak vagy eltávolíthatnak.

Az Actions mellett a Gitea 1.27 natív megjelenítést kapott a Jupyter Notebook fájlokhoz. Az .ipynb kiterjesztésű fájlok mostantól formázott notebookként jelennek meg a generált kimenettel együtt, nem pedig nyers JSON-ként.

A problémákat és pull requesteket mostantól egyszerre több projekthez is hozzá lehet rendelni, a projektoszlopokat pedig közvetlenül a probléma sidebarból lehet kiválasztani. A fájlok előzményeinél megjelent egy új opció, amellyel az átnevezéseken keresztül is követhető a fájl, így a commit-előzmények a névváltoztatás után is láthatók maradnak.

További tároló- és együttműködési fejlesztés a kompakt avatar stack, a bővített szintaxiskiemelés a kerítéssel jelölt Markdown kódrészletekhez, a kereshető szervezeti taglista és a könnyebben felfedezhető szervezeti csapatok. Az adminisztrátorok mostantól külön-külön állíthatják be a tároló-létrehozási limiteket a személyes fiókokra és a szervezetekre.

API-oldalon a Gitea mostantól OpenAPI 3.0 specifikációt tesz közzé a /openapi.v1.json címen, ami megkönnyíti a kliensgenerálást és az integrációt külső fejlesztőeszközökkel. A kiadás új endpointokat is bevezet a jelenlegi hozzáférési token vizsgálatához, a token önálló törléséhez, a problémák és pull requestek felelőseinek kezeléséhez, valamint az adott workflow-hoz tartozó workflow futások listázásához.

Biztonság szempontjából ez a kiadás 45 dokumentált CVE-t kezel. A javítások között szerepel jogosultságkiterjesztés, szerveroldali kéréshamisítás, jogosultság- és token-hatókör megkerülése, privát tárolók és szervezeti információk kiszivárgása, branch-védelem megkerülése, helyi fájlbeillesztés, munkamenet-újrafelhasználás és több szolgáltatásmegtagadási hiba.

További részletekért lásd a bejelentést. Verziófrissítés előtt a felhasználók ezúttal is készítsenek biztonsági mentést, majd cseréljék a binárist vagy a Docker konténert, és indítsák újra a szolgáltatást.