Megjelent a 13.4-es kiadás, amely tartalmazza a HashiCorp tárhelyet a CI-változókhoz, a Kubernetes Agentet és a biztonsági központot, valamint a Starter váltható funkcióit
A GitLabnál mindig azon gondolkodunk, hogyan segíthetnénk a felhasználókat a kockázat csökkentésében, a hatékonyság növelésében és a kézbesítési sebesség javításában kedvenc platformján. Ebben a hónapban sok hasznos új funkciót adtunk hozzá, amelyek bővítik a biztonsági lehetőségeket, csökkentik a sebezhetőségek számát, növelik a hatékonyságot, leegyszerűsítik a GitLabbal való munkát, és segítenek csapatának még gyorsabban szállítani a szolgáltatásokat. Reméljük, hogy hasznosnak találja a kiadás főbb funkcióit, valamint 53 további újdonság, hozzáadva ebben a kiadásban.
Speciális biztonsági szolgáltatások
Igyekszünk minden hónapban több új funkciót hozzáadni a GitLab DevSecOpshoz, és ez a kiadás sem kivétel. összeszerelés és bevetés keretein belül. Ezenkívül azok a szervezetek, amelyek támogatni kívánják a kódtelepítési felelősségek szétválasztását, most megtehetik . Ez a szerep megfelel és lehetővé teszi az egyesítési kérelmek megerősítését (a GitLab „egyesítési kérelmek” orosz nyelvű lokalizációjában), és a kód biztonságos környezetekben történő telepítését anélkül, hogy hozzáférést biztosítana magának a kódnak a módosításához.
A kockázatok csökkentésének másik módja az újak használata . Az üzemeltetési csapatok anélkül telepíthetik a Kubernetes-fürtöket a GitLabból, hogy a fürtjüket a teljes internet számára ki kellene mutatniuk. Ezenkívül bevezetjük az automatikus verzióvezérlési támogatást az új Terraform állapotfájlokhoz a megfelelőség és a hibakeresés megkönnyítése érdekében. Végül a példány biztonsági irányítópultja lett sebezhetőségi jelentésekkel és biztonsági beállításokkal.
Kényelmesebb és hatékonyabb munkavégzés a GitLab segítségével
Javítottuk globális keresésünket, hogy az is tartalmazza , amellyel könnyedén navigálhat a legújabb jegyekhez, csoportokhoz, projektekhez, beállításokhoz és súgótémákhoz. Örömmel jelentjük be, hogy a GitLab Pages az egyes oldalak és könyvtárak átirányítása a webhelyen belül, ami lehetővé teszi a felhasználók számára, hogy hatékonyabban telepítsék webhelyeiket. Azok számára pedig, akik szeretnének bővebb tájékoztatást kapni a telepítésről, ez a kiadás lehetővé teszi !
Nyílt forráskódú hozzájárulások
Jelen voltak amit hozzátettem . A megváltozott kód egységteszt-lefedettségén lévő jelölések világos képet adnak a fejlesztőknek a kód lefedettségéről a felülvizsgálat során; ezek az információk felgyorsítják az áttekintést, és csökkentik az új kód egyesítéséhez és telepítéséhez szükséges időt. És mi is és tervezni .
És ez még csak a kezdet!
Mint mindig, most is túl kevés hely van az általános áttekintésben, de a 13.4-es kiadásban sok nagyszerű funkció található. Itt van még néhány:
- .
Ha szeretnéd előre tudni, hogy mi vár rád következő engedje el, nézze meg .
.
ebben a hónapban -
Fabio jelentősen hozzájárult в - egy olyan funkció, amelyet nagyon régóta várnak a GitLab közösségben. Ez valóban fontos hozzájárulás a nem triviális változtatásokhoz, amelyek folyamatos együttműködést igényeltek a GitLab csapat tagjaival, és a projekt számos területét érintette, például az UX-et, a front-endet és a háttérrendszert.
A GitLab 13.4 kiadás főbb jellemzői
Használja a HashiCorp Vault kulcsokat a CI-feladatokban
(PREMIUM, ULTIMATE, EZÜST, ARANY)
A 12.10-es kiadásban a GitLab bevezette a kulcsok fogadásának és átvitelének lehetőségét a CI-feladatokhoz a GitLab jobkezelő (GitLab runner) segítségével. Most terjeszkedünk , új szintaxis hozzáadása secrets fájlhoz .gitlab-ci.yml. Ez megkönnyíti a HashiCorp adattárának beállítását és használatát a GitLab segítségével.
и .
Bemutatkozik a GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
A GitLab és a Kubernetes integrációja már régóta lehetővé tette a Kubernetes-fürtökbe történő telepítést manuális konfigurálás nélkül. Sok felhasználónak tetszett a csomag egyszerű használata, míg másoknak nehézségekbe ütköztek. A jelenlegi integrációhoz a fürtnek elérhetőnek kell lennie az internetről, hogy a GitLab hozzáférhessen. Sok szervezet számára ez nem lehetséges, mert biztonsági, megfelelőségi vagy szabályozási okokból korlátozzák a fürtökhöz való hozzáférést. A korlátozások megkerüléséhez a felhasználóknak a GitLab tetejére kellett építeniük eszközeiket, különben nem tudnák használni ezt a funkciót.
Ma bemutatjuk a GitLab Kubernetes Agentet, amely a Kubernetes-fürtökben való üzembe helyezés új módja. Az ügynök a fürtön belül fut, így nem kell kitennie a teljes internet számára. Az ügynök úgy koordinálja a telepítést, hogy új módosításokat kér a GitLabtól, ahelyett, hogy a GitLab frissítéseket küldene a fürtnek. Függetlenül attól, hogy milyen GitOps-módszert használ, a GitLab mindent megtesz.
Felhívjuk figyelmét, hogy ez az ügynök első kiadása. A GitLab Kubernetes Agent jelenlegi célja a központi telepítések kódon keresztüli konfigurálása és kezelése. Egyes meglévő Kubernetes-integrációs funkciók, például a telepítési táblák és a GitLab által felügyelt alkalmazások még nem támogatottak. hogy ezeket a képességeket a jövőbeni kiadásokban, valamint a biztonságra és megfelelőségre összpontosító új integrációkban hozzáadják az ügynökhöz.
и .
Adjon a felhasználóknak telepítési engedélyeket kódhozzáférés nélkül
(PREMIUM, ULTIMATE, EZÜST, ARANY)
Korábban a GitLab engedélyrendszere megnehezítette a felelősségek megfelelő megosztását a csapaton belül a fejlesztésért és a telepítésért felelős személyek között. A GitLab 13.4 kiadásával engedélyt adhat a telepítési kérelmek jóváhagyására, valamint a kód tényleges telepítésére olyan személyek számára, akik nem írják a kódot, anélkül, hogy fenntartói hozzáférési jogokat adnának (a GitLab „karbantartó” orosz nyelvű lokalizációjában). ).
и .
Biztonsági Központ
(ULTIMATE, ARANY)
Korábban a példányszintű sebezhetőség-kezelés mind a funkcionalitás, mind a rugalmasság tekintetében korlátozott volt. A felület egyetlen oldal volt, amely egyesíti a sebezhetőségek részleteit, a mérőszámok grafikonjait és a beállításokat. Nincs sok hely ezeknek a funkcióknak a fejlesztésére vagy más biztonsági funkciók használatára.
Alapvető változtatásokat hajtottunk végre a GitLab biztonságának és átláthatóságának kezelésében. A példány biztonsági panelje egy teljes biztonsági központtá alakult. A legnagyobb változást az új menüstruktúra bevezetése jelenti: egy oldal helyett mostantól külön látható a biztonsági műszerfal, a sebezhetőségi jelentés és a beállítások rész. Bár a funkcionalitás nem változott, részekre bontása lehetővé teszi ennek a szakasznak a fejlesztését, amely egyébként nehéz lenne. Ez megteremti a terepet más, biztonsággal kapcsolatos képességek jövőbeli hozzáadásához is.
A dedikált sebezhetőségi jelentés részben több hely van a fontos részletek megjelenítéséhez. Itt vannak azok a biztonsági rések, amelyek jelenleg szerepelnek a projekt sebezhetőségi listáján. A sebezhetőségi mutatókat tartalmazó widgetek külön szakaszba helyezése kényelmes biztonsági vezérlőpultot eredményez. Mostantól a jövőbeni vizualizációk vászonává válik – nemcsak a sebezhetőségek kezeléséhez, hanem a biztonsággal kapcsolatos mérőszámokhoz is. Végül egy külön beállítási terület közös teret hoz létre az összes példányszintű biztonsági beállításhoz, nem csak a sebezhetőség-kezeléshez.
и .
A váltható funkciók már elérhetők a GitLab Starterben
(STARTER, PREMIUM, ULTIMATE, BRONZ, EZÜST, ARANY)
Megjelent a GitLab 11.4 . A 12.2-ben stratégiákat mutattunk be számukra и , és a 13.1-ben hozzáadták и különböző környezetekhez.
Az év elején a GitLab kötelezettséget vállalt nyílt forráskódba. Ebben a kiadásban befejeztük az átkapcsolható funkciók áttelepítését a Starter csomagba, és továbbra is áttelepítjük őket a Core-ba . Izgatottan várjuk, hogy ezt a funkciót több felhasználóhoz eljuttassuk, és szeretnénk hallani, hogyan használja.
и .
Gyors navigáció a keresősávból
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Néha a GitLab navigációja során a keresési eredményoldal helyett közvetlenül egy adott projektre szeretne lépni.
A globális keresősáv segítségével gyorsan navigálhat a legújabb jegyekhez, csoportokhoz, projektekhez, beállításokhoz és súgótémákhoz. Akár gyorsbillentyűt is használhat /mozgassa a kurzort a keresősávra a GitLab még hatékonyabb navigálása érdekében!
и .
Kódlefedettség megjelenítése az összevonási kérelem eltéréseiben
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Az összevonási kérelem áttekintése során nehéz lehet megállapítani, hogy a módosított kódot lefedik-e az egységtesztek. Ehelyett a felülvizsgálók a teljes lefedettségre hagyatkozhatnak, és kérhetik annak növelését, mielőtt jóváhagyják az egyesítési kérelmet. Ez a tesztírás véletlenszerű megközelítéséhez vezethet, ami valójában nem javítja a kód minőségét vagy a tesztek lefedettségét.
Most, amikor egy összevonási kérelem diff-et néz, megjelenik a kód lefedettségének vizuális megjelenítése. Az új jelölések segítségével gyorsan megértheti, hogy a megváltozott kódot lefedi-e az egységteszt, ami segít felgyorsítani a kód áttekintését, valamint az egyesítés és az új kód telepítésének idejét.
Köszönöm és a Siemensnek ezért a funkcióért!
и .
További környezetek és projektek a Környezetek panelen
(PREMIUM, ULTIMATE, EZÜST, ARANY)
A GitLab 12.5 megjelenése óta használja monitorozhatja a környezetek állapotát, de legfeljebb hét környezetet három projektben. Ezt a panelt a 13.4-es kiadásban oldalszámozással továbbfejlesztettük, hogy segítsünk a környezetek nagyarányú karbantartásában és kezelésében. Most több környezetet láthat több projektben.
и .
A GitLab átveszi az irányítást a GitLab Terraform szolgáltató felett
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Nemrég mi és tervezni . Az elmúlt hónapban 21 összevonási kérelmet fogadtunk el és 31 jegyet zártunk le, beleértve néhány régóta fennálló hibát és hiányzó funkciókat, mint pl. ... tudsz a Terraform dokumentációjában.
и .
Összezavaró API-tesztelés OpenAPI-specifikációkkal vagy HAR-fájllal
(ULTIMATE, ARANY)
Az API fuzzing tesztelése nagyszerű módja annak, hogy megtalálja a webalkalmazásokban és API-kban lévő hibákat és sebezhetőségeket, amelyeket más szkennerek és tesztelési módszerek esetleg figyelmen kívül hagynak.
A GitLab API-fuzzing tesztelése lehetővé teszi vagy az alkalmazást, majd automatikusan generál véletlenszerű bemeneti adatokat, amelyek az éles esetek tesztelésére és a hibák felderítésére szolgálnak. Az eredmények azonnal láthatóak a folyamatban.
Ez az első API-fuzz-tesztelési kiadásunk, és szeretnénk hallani az Ön véleményét. Több készletünk van fuzz teszteléshez , amelyet ennek a funkciónak a kiadására fogunk alapozni.
и .
Tekintse meg az új grafikonok előnézetét a mérőszámok panelen
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Korábban a grafikonok létrehozása a metrikák irányítópultján a GitLabban nem volt egyszerű feladat. Miután létrehozta a mérőszámot az irányítópult YAML-fájljában, módosította master, anélkül, hogy ellenőrizhetné, hogy az újonnan létrehozott grafikon pontosan úgy működik-e, ahogyan szüksége van rá. Ettől a kiadástól kezdve megtekintheti a változtatások előnézetét a grafikon létrehozásakor, és képet kaphat az eredményről, mielőtt elküldi a változtatásokat az irányítópult YAML-fájljába.
и .
A kód lefedettségére vonatkozó adatok tesztekkel a csoport összes projektjére vonatkozóan
(PREMIUM, ULTIMATE, EZÜST, ARANY)
Ha nagyszámú projektet kezel a GitLabban, egyetlen információforrásra van szüksége arról, hogy a kód lefedettsége hogyan változik az idő múlásával az összes projektben. Korábban ezeknek az információknak a megjelenítése fárasztó és időigényes manuális munkát igényelt: minden projektből le kellett tölteni a kódlefedettségi adatokat, és táblázatba kell foglalni.
A 13.4-es kiadásban lehetővé vált a gyors és egyszerű összeszerelés .csv fájl tartalmazza a kódlefedettség összes adatát a csoport összes projektjére vagy kiválasztott projektekre vonatkozóan. Ez a funkció az MVC, ezt követi majd a képesség .
и .
Új nyelvek támogatása a teljes fuzz teszteléshez
(ULTIMATE, ARANY)
Ez a kiadás számos új nyelv támogatását vezeti be a teljes lefedettséget célzó fuzz teszteléshez.
Mostantól kiértékelheti a Java-, Rust- és Swift-alkalmazásaiban a fuzzing tesztelés teljes képességét, és megtalálhatja azokat a hibákat és sebezhetőségeket, amelyeket más szkennerek és tesztelési módszerek kihagyhatnak.
и .
Figyelmeztetések a fő környezeti oldalon
(PREMIUM, ULTIMATE, EZÜST, ARANY)
A Környezetek oldalon a környezetek általános állapota látható. Ebben a kiadásban javítottuk ezt az oldalt a figyelmeztető megjelenítés hozzáadásával. A kiváltott riasztások és a környezet állapota segít gyorsan intézkedni a felmerülő helyzetek kijavítása érdekében.
и .
A beágyazott folyamatok mostantól futtathatják saját beágyazott folyamataikat
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A beágyazott folyamatok használatával most már lehetséges új folyamatok futtatása a gyermekfolyamatokon belül. Az extra mélységi szint akkor lehet hasznos, ha rugalmasságra van szüksége változó számú csővezeték létrehozásához.
Korábban beágyazott folyamatok használatakor minden egyes alárendelt folyamathoz egy aktiválási feladatot kellett manuálisan megadni a szülőfolyamatban. Mostantól beágyazott folyamatokat hozhat létre, amelyek dinamikusan elindítanak tetszőleges számú új beágyazott folyamatot. Például, ha van egy tárolója, akkor dinamikusan generálhatja az első részfolyamatot, amely maga is létrehozza a szükséges számú új folyamatot az ág változásai alapján.
и .
Továbbfejlesztett navigáció a szülő és a beágyazott folyamatok között
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Korábban a szülő és a beágyazott folyamatok közötti navigáció nem volt túl kényelmes – sok kattintásra volt szükség, hogy elérje a kívánt folyamatot. Azt sem volt könnyű kitalálni, hogy melyik munkából indult ki a folyamat. Most sokkal könnyebb lesz látni a kapcsolatokat a szülő és a beágyazott folyamatok között.
и .
A párhuzamos mátrixos munkák releváns változókat jelenítenek meg a munkakör megnevezésében
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Ha használtad , észrevehette, hogy nehéz volt meghatározni, melyik mátrixváltozót használták egy adott munkához, mivel a munkanevek így néztek ki matrix 1/4. A 13.4-es kiadásban az általános jobnév helyett az adott jobban használt releváns változóértékeket fogja látni. Például, ha a cél az x86 architektúra hibakeresése, akkor a feladat meghívásra kerül matrix: debug x86.
и .
Egyéb fejlesztések a GitLab 13.4-ben
Atlassian fiók csatlakoztatása
(CORE, STARTER, PREMIUM, ULTIMATE)
A GitLab-felhasználók mostantól összekapcsolhatják GitLab-fiókjukat Atlassian Cloud-fiókjukkal. Ez lehetővé teszi, hogy Atlassian hitelesítő adataival bejelentkezzen a GitLabba, és megalapozza a jövőbeni integrációs fejlesztéseket. és más Atlassian termékcsaláddal.
и .
Az összes összevonási véglegesítés listájának exportálása
(ULTIMATE, ARANY)
A megfelelésre összpontosító szervezeteknek módot kell adni arra, hogy az auditoroknak holisztikus képet mutassanak a termelésben bekövetkezett bármely változáshoz kapcsolódó összetevőkről. A GitLab-ban ez azt jelenti, hogy mindent egy helyen kell összegyűjteni: az összevonási kérelmeket, jegyeket, csővezetékeket, biztonsági vizsgálatokat és egyéb véglegesítési adatokat. Eddig vagy manuálisan kellett összegyűjtenie a GitLab-ban, vagy konfigurálnia kellett az eszközöket az információgyűjtéshez, ami nem volt túl hatékony.
Mostantól programozottan gyűjtheti és exportálhatja ezeket az adatokat, hogy megfeleljen az ellenőrzési követelményeknek, vagy más elemzéseket végezzen. Az aktuális csoport összes egyesítési véglegesítési listájának exportálásához lépjen a következő helyre: és kattintson a gombra Az összes összevonási véglegesítés listája. Az eredményül kapott fájl tartalmazza az összevonási kérelem összes véglegesítését, azok szerzőjét, a kapcsolódó összevonási kérelem azonosítóját, csoportot, projektet, megerősítőket és egyéb információkat.
и .
Személyes hozzáférési tokenek listázása és kezelése API-n keresztül
(ULTIMATE, ARANY)
A GitLab névtérhez való hozzáférés kezelése a megfelelőségi erőfeszítések fontos része. A legkisebb jogosultság elvétől az időzített hozzáférés letiltásáig számos követelmény vonatkozhat a GitLab személyes hozzáférési jogkivonataira. A névtéren belüli összes felhasználói hitelesítő adatok karbantartásának és kezelésének megkönnyítése érdekében lehetőséget biztosítottunk az összes személyes hozzáférési token felsorolására, és opcionálisan API-n keresztül.
A GitLab API ezen fejlesztései lehetővé teszik a felhasználók számára, hogy listázzák és visszavonják saját személyes hozzáférési jogkivonataikat, az adminisztrátorok pedig listázzák és visszavonják felhasználói tokenjeit. Az adminisztrátorok ezentúl könnyebben láthatják, ki fér hozzá a névterükhöz, felhasználói adatok alapján hozzáférhet a hozzáféréssel kapcsolatos döntésekhez, és visszavonhatja azokat a személyes hozzáférési jogkivonatokat, amelyeket esetleg feltörtek, vagy amelyek kívül esnek a vállalat hozzáférés-kezelési szabályzatán.
и .
A kapcsolódó problémák és egyéb szolgáltatások már megtalálhatók a GitLab Core-ban
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Néhány hónappal ezelőtt bejelentettük a tervünket . Azzal, hogy ezen ígéretünk betartásán dolgozunk, megtettük , и (a GitLab „vitafórum” orosz nyelvű lokalizációjában) elérhető az Alaptervben. Ez csak a „kapcsolt” kapcsolatokra vonatkozik; a „blokkolt” és „blokkolt” kapcsolatok a fizetős csomagokban maradnak.
и .
Az eredet ág nevének megjelenítése az egyesítési kérelem oldalsávjában
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A kódmódosítások, megbeszélések és egyesítési kérelmek áttekintése során gyakran kívánatos az ág helyi ellenőrzése a mélyebb áttekintés érdekében. A szál nevének megtalálása azonban egyre nehezebbé válik, mivel több tartalom kerül hozzáadásra az egyesítési kérelem leírásához, és lejjebb kell görgetnie az oldalon.
Az ág nevét hozzáadtuk az egyesítési kérelem oldalsávjához, így bármikor elérhetővé tesszük, és szükségtelenné teszi a teljes oldal görgetését. Csakúgy, mint az egyesítési kérelem hivatkozása, a forrás ág része egy kényelmes „másolás” gombot.
Köszönöm a funkció fejlesztéséhez nyújtott hatalmas hozzájárulásáért!
и .
Összeomlott fájlok jelenlétének jelzése az összevonási kérelem diffekben
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A több fájlt módosító összevonási kérelmek időnként összecsukják a nagy fájlok eltéréseit a renderelési teljesítmény javítása érdekében. Ha ez megtörténik, előfordulhat, hogy az ellenőrzés során véletlenül átugorjon egy fájlt, különösen a nagy számú fájlt tartalmazó egyesítési kérelmek esetén. A 13.4-es verziótól kezdődően az egyesítési kérelmek megjelölik azokat a különbségeket, amelyek hajtogatott fájlokat tartalmaznak, így ezekről a fájlokról nem fog hiányozni a kódellenőrzés során. A még nagyobb áttekinthetőség érdekében azt tervezzük, hogy egy későbbi kiadásban kiemeljük ezeket a fájlokat. Maradjon velünk a frissítésekkel kapcsolatban .
и .
Figyelmeztetés összeomlott fájlok jelenlétére az egyesítési kérelem diff-jében
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Az összevonási kérelem diff. szakaszában a nagy fájlok összecsukódnak a teljesítmény javítása érdekében. A kód áttekintése során azonban előfordulhat, hogy néhány fájl kimarad, amikor a lektor a fájlok listáján görget, mivel minden nagy fájl össze van csukva.
Látható figyelmeztetést adtunk az összevonási kérelem diff oldalának tetejére, hogy tájékoztassuk a felhasználókat arról, hogy ebben a részben egyesített fájl található. Így nem marad le az egyesítési kérelem módosításáról a felülvizsgálat során.
и .
A Gitaly-fürt tárolójának automatikus helyreállítása
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Korábban, amikor egy Gitaly-fürt elsődleges csomópontja offline állapotba került, a csomóponton lévő tárolók csak olvashatóként voltak megjelölve. Ez megakadályozta az adatvesztést olyan helyzetekben, amikor a csomóponton olyan változások történtek, amelyeket még nem replikáltak. Amikor a csomópont újra online állapotba került, a GitLab nem állt vissza automatikusan, és a rendszergazdáknak kézzel kellett elindítaniuk a szinkronizálási folyamatot, vagy el kellett fogadniuk az adatvesztést. Más helyzetek, például egy másodlagos csomóponton lévő replikációs feladat meghibásodása is elavult vagy csak olvasható lerakathoz vezethet. Ebben az esetben a lerakat elavult maradt a következő írási műveletig, amely elindította a replikációs feladatot.
A probléma megoldásához most ütemez egy replikációs feladatot, ha az egyik csomóponton elavult lerakat, a másikon pedig a lerakat legújabb verzióját észleli. Ez a replikációs feladat automatikusan naprakészen tartja a lerakat, így nincs szükség az adatok kézi visszaállítására. Az automatikus helyreállítás azt is biztosítja, hogy a másodlagos csomópontok gyorsan naprakészek legyenek, ha egy replikációs feladat meghiúsul, ahelyett, hogy a következő írási műveletre várnának. Mivel sok Gilaly-fürt nagyszámú adattárat tárol, ez jelentősen csökkenti azt az időt, amelyet a rendszergazdák és a megbízhatósági mérnökök az adatok hiba utáni helyreállításával töltenek.
Ezenkívül az automatikus javítás elindítja a lerakat replikációját a fürthöz hozzáadott bármely új Gitaly-csomóponton, kiküszöbölve a kézi munkát az új csomópontok hozzáadásakor.
и .
Jelöljön meg egy teendőt befejezettként a tervezési oldalon
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab hatékony kommunikációja a teendőlistákon alapul. Ha megemlítenek egy megjegyzésben, nagyon fontos, hogy ugorjon egy feladatra, és vagy elkezdjen valamit csinálni, vagy megjelölje azt befejezettként. Az is fontos, hogy tudjunk feladatot kijelölni magunknak, amikor valamin dolgozni kell, vagy később vissza kell térnie hozzá.
Korábban nem lehetett feladatokat hozzáadni vagy befejezettként megjelölni, amikor tervekkel dolgozott. Ez súlyosan megzavarta a termékcsapatok közötti kommunikáció hatékonyságát, mivel a teendők a GitLab munkafolyamatának kritikus elemei.
A 13.4-es kiadásban a tervek utolérik a jegyek megjegyzéseit a feladatok használatában, ami következetesebbé és hatékonyabbá teszi a velük való munkát.
и .
Továbbfejlesztett hibaelhárítási útmutató CI/CD-hez
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Továbbfejlesztettük a GitLab CI/CD hibaelhárítási útmutatóját, amely további információkat tartalmaz az esetlegesen felmerülő gyakori problémákról. Reméljük, hogy a továbbfejlesztett dokumentáció értékes forrás lesz a GitLab CI/CD gyors és egyszerű üzembe helyezésében és futtatásában.
и .
Az egyesítési kérelmek többé nem esnek ki az egyesítési sorból
(PREMIUM, ULTIMATE, EZÜST, ARANY)
Korábban az összevonási kérelmek véletlenül kieshettek az egyesítési sorból a késői megjegyzések miatt. Ha egy összevonási kérelem már a sorban volt, és valaki olyan megjegyzést adott hozzá, amely új, megoldatlan vitát hozott létre, akkor az összevonási kérelem nem alkalmas az összevonásra, és kiesik a sorból. Most, miután egy egyesítési kérelmet hozzáadtak az egyesítési sorhoz, új megjegyzések adhatók hozzá anélkül, hogy attól kellene tartani, hogy az összevonási folyamat megszakadna.
и .
Egy feladat kódlefedettségi értékének megjelenítése egy egyesítési kérelemben
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A fejlesztőknek látniuk kell a kódlefedettség értékét a folyamat befejezése után – még olyan összetett forgatókönyvek esetén is, mint például egy folyamat futtatása több feladattal, amelyeket elemezni kell a lefedettség értékének kiszámításához. Korábban az összevonási kérelem widget csak ezeknek az értékeknek az átlagát mutatta, ami azt jelentette, hogy a köztes lefedettségi értékekhez a munkaoldalra kellett navigálnia, majd vissza az egyesítési kérelemhez. Az idő és az extra lépések megtakarítása érdekében a widget megjeleníti az átlagos lefedettségi értéket, annak változásait a cél és a forrás ágak között, valamint egy eszköztippet, amely megmutatja a lefedettség értékét minden egyes munkához, amely alapján az átlagot kiszámítottuk.
и .
Csomagok eltávolítása a csomagnyilvántartásból csoport megtekintésekor
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab csomag-nyilvántartása egy hely a különböző formátumú csomagok tárolására és terjesztésére. Ha sok csomag van a projektben vagy csoportban, gyorsan azonosítania kell a fel nem használt csomagokat, és el kell távolítania őket, hogy megakadályozza az emberek letöltését. A rendszerleíró adatbázisból a csomagokat a következőn keresztül távolíthatja el vagy a csomagnyilvántartás felhasználói felületén keresztül. Mindeddig azonban nem lehetett eltávolítani a csomagokat, amikor egy csoportot a felhasználói felületen keresztül nézett meg. Ennek eredményeként projektenként el kellett távolítania a szükségtelen csomagokat, ami nem volt hatékony.
Mostantól eltávolíthatja a csomagokat egy csoport csomag-nyilvántartásának megtekintésekor. Egyszerűen lépjen a csoport csomag-nyilvántartási oldalára, szűrje a csomagokat név szerint, és távolítsa el azokat, amelyekre nincs szüksége.
и .
Conan-csomagok méretezése projektszintre
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab Conan tárházát használhatja C/C++ függőségek közzétételére és terjesztésére. Korábban azonban a csomagok csak példányszintre méretezhettek, mivel a Conan csomag neve legfeljebb 51 karakterből állhatott. Ha például egy alcsoportból szeretne csomagot közzétenni gitlab-org/ci-cd/package-stage/feature-testing/conan, szinte lehetetlen volt megtenni.
Mostantól a Conan-csomagokat projektszintre méretezheti, így könnyen közzéteheti és terjesztheti projektjei függőségeit.
и .
Új csomagkezelők és nyelvek támogatása a függőségi vizsgálathoz
(ULTIMATE, ARANY)
Izgatottan várjuk, hogy a NuGet 4.9+ vagy Conan csomagkezelőket használó C, C++, C# és .Net code projektek függőségi vizsgálatait felvehessük listánkra . Mostantól a Biztonsági szakasz részeként engedélyezheti a függőségi vizsgálatot, hogy ellenőrizze a csomagkezelőn keresztül hozzáadott függőségek ismert sebezhetőségét. A talált sebezhetőségek megjelennek az egyesítési kérelemben a súlyossági szintjükkel együtt, így az összevonás végrehajtása előtt tudni fogja, milyen kockázatokat rejt az új függőség. A projektet igény szerint is konfigurálhatja kritikus (kritikus), magas (magas) vagy ismeretlen (ismeretlen) súlyosságú biztonsági résekkel rendelkező függőségek esetén.
и .
Értesítések az egyesítési kérelem beállításának „Egyesítés, ha a folyamat sikeresen befejeződött” értékre módosítva
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Korábban az egyesítési kérelem beállításainak megadásakor Egyesítés, amikor a folyamat befejeződik (Merge When Pipeline Succeed, MWPS) nem küldtek e-mailes értesítést. Manuálisan kellett ellenőriznie az állapotot, vagy meg kellett várnia az összevonási értesítést. Ezzel a kiadással örömmel mutatjuk be a felhasználói hozzájárulásokat , amely megoldotta ezt a problémát azáltal, hogy automatikus értesítést adott mindenkinek, aki feliratkozott az összevonási kérelemre, amikor egy ellenőr az egyesítési beállítást MWPS-re módosítja.
и .
EKS-fürtök létrehozása a Kubernetes felhasználó által megadott verziójával
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab-felhasználók most kiválaszthatják a Kubernetes EKS által biztosított verzióját; választhat az 1.14–1.17 verziók közül.
и .
Incidensek létrehozása jegytípusként
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Nem minden felmerülő probléma azonnal riasztást vált ki: a felhasználók jelentenek kimaradásokat, a csapattagok pedig kivizsgálják a teljesítményproblémákat. Az incidensek ma már egyfajta jegynek számítanak, így a csapatok gyorsan létrehozhatják azokat normál munkafolyamataik részeként. Kattintson Új feladat bárhonnan a GitLabból és a terepen Type választ Incidens.
и .
A GitLab figyelmeztetések megemlítése a Markdownban
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Javítottuk a GitLab-figyelmeztetéseket azáltal, hogy új említési típust adtunk hozzá a GitLab Markdown-ban, ami megkönnyíti a riasztások megosztását és említését. Használat ^alert#1234hogy megemlítse a figyelmeztetést bármely Markdown mezőben: incidenseknél, jegyeknél vagy egyesítési kéréseknél. Ez segít azonosítani azokat a munkákat is, amelyek riasztásokból jönnek létre, nem pedig jegyekből vagy egyesítési kérésekből.
и .
A riasztási terhelés megtekintése eseményenként
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A riasztás leírása a hibaelhárítás és helyreállítás szempontjából kritikus információkat tartalmaz, és ezeknek az információknak könnyen hozzáférhetőnek kell lenniük, hogy ne kelljen eszközöket vagy lapot váltania az incidens megoldása során. A riasztásokból létrehozott incidensek a teljes riasztás leírást jelenítik meg a lapon Figyelmeztetés részletei.
75%-kal gyorsabb speciális keresés
(STARTER, PREMIUM, ULTIMATE, BRONZ, EZÜST, ARANY)
A GitLab egyetlen alkalmazásként egyedülálló képességgel rendelkezik, hogy a teljes DevOps-munkafolyamatban gyors tartalomfeltárást biztosítson. A GitLab 13.4-ben a speciális keresés 75%-kal gyorsabban adja vissza az eredményeket , mint a GitLab.com-on.
и .
Törölt projektek megtekintése rendszergazdák számára
(CORE, STARTER, PREMIUM, ULTIMATE)
Lehetőség volt a projekt törlésének elhalasztására . Korábban azonban nem lehetett egy helyen látni az összes törlésre váró projektet. A GitLab felhasználói példányok adminisztrátorai mostantól egy helyen tekinthetik meg az összes függőben lévő törlési projektet, valamint a projektek egyszerű visszaállításához szükséges gombokat.
Ez a funkció lehetővé teszi az adminisztrátorok számára, hogy nagyobb ellenőrzést gyakoroljanak a projekttörlés felett, mivel az összes releváns információt egy helyen gyűjtik össze, és lehetővé teszik a nem kívánt törlési műveletek visszavonását.
Köszönöm ehhez a funkcióhoz!
и .
A csoportos leküldési szabályok támogatása hozzáadva az API-hoz
(STARTER, PREMIUM, ULTIMATE, BRONZ, EZÜST, ARANY)
Korábban a csoportos leküldési szabályokat csak úgy lehetett konfigurálni, hogy minden csoportot külön-külön meglátogattak a GitLab UI-n keresztül, és alkalmazták ezeket a szabályokat. Ezeket a szabályokat mostantól API-n keresztül is kezelheti az egyéni eszközök és a GitLab automatizálás támogatása érdekében.
и .
Személyes hozzáférési jogkivonatok visszavonása a saját maga által kezelt hitelesítő adatok tárolására
(VÉGSŐ)
Biztosítja a rendszergazdák számára a GitLab-példány felhasználói hitelesítő adatainak kezeléséhez szükséges információkat. Mivel a megfelelésre összpontosító szervezetek hitelesítőadat-kezelési szabályzataik szigorúsága eltérő, hozzáadtunk egy gombot, amely lehetővé teszi a rendszergazdák számára, hogy tetszés szerint visszavonják a felhasználók személyes hozzáférési jogkivonatát (PAT). Az adminisztrátorok mostantól könnyedén visszavonhatják a potenciálisan feltört PAT-okat. Ez a funkció olyan szervezetek számára hasznos, amelyek rugalmasabb megfelelési lehetőségeket szeretnének, hogy minimálisra csökkentsék felhasználóik zavarását.
и .
A statikus webhelyszerkesztő konfigurációs fájlja
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab 13.4-ben új módszert vezetünk be a statikus webhelyszerkesztő testreszabására. Bár a konfigurációs fájl nem menti és nem fogad semmilyen beállítást ebben a kiadásban, lefektetjük az alapot a szerkesztő viselkedésének jövőbeni testreszabásához. A jövőbeni kiadásokban hozzáadjuk a fájlt .gitlab/static-site-editor.yml paraméterek a telepítéshez , amelyen , felülírja a Markdown szintaxis beállításait és más szerkesztőbeállításokat.
и .
Fájl bevezető részének szerkesztése statikus webhelyszerkesztővel
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A Front matter rugalmas és kényelmes módja az oldalváltozók adatfájlokban történő meghatározásának a statikus webhelygenerátor általi feldolgozásra. Általában az oldal címének, elrendezési sablonjának vagy szerzőjének beállítására szolgál, de bármilyen típusú metaadat átadására használható a generátornak, amikor az oldalt HTML-ben jeleníti meg. Minden adatfájl legtetején található bevezető rész általában YAML vagy JSON formátumban van formázva, és következetes és pontos szintaxist igényel. Azok a felhasználók, akik nem ismerik az adott szintaktikai szabályokat, véletlenül érvénytelen jelölést írhatnak be, ami formázási problémákat vagy akár összeállítási hibákat is okozhat.
A statikus webhelyszerkesztő WYSIWYG szerkesztési módja már eltávolítja a bevezetőt a szerkesztőből, hogy elkerülje ezeket a formázási hibákat. Ez azonban megakadályozza, hogy módosítsa az ebben a részben tárolt értékeket anélkül, hogy visszatérne a forrás módban történő szerkesztéshez. A GitLab 13.4-ben bármelyik mezőt elérheti, és szerkesztheti annak értékét egy ismerős űrlap-alapú felületen. A gomb megnyomásakor beállítások (beállítások) megnyílik egy panel, amely egy űrlapmezőt mutat minden, az elején meghatározott kulcshoz. A mezők az aktuális értékkel vannak feltöltve, és bármelyik szerkesztése olyan egyszerű, mint beírni a webes űrlapba. A bevezető ily módon történő szerkesztése elkerüli a bonyolult szintaxist, és teljes ellenőrzést biztosít a tartalom felett, miközben biztosítja a végeredmény következetes formázását.
и .
A GitLab for Jira és a DVCS Connector már a Core-ban van
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Jira-felhasználók számára a GitLabon: и lehetővé teszi, hogy közvetlenül a Jira-ban jelenítsen meg információkat a GitLab végrehajtási és egyesítési kérelmeiről. A beépített Jira-integrációnkkal kombinálva könnyedén mozoghat a két alkalmazás között munka közben.
Ezek a funkciók korábban csak a prémium csomagunkban voltak elérhetők, de most már minden felhasználó számára elérhetőek!
и .
A Gitaly-fürttranzakciókra vonatkozó többségi szavazás (béta)
(CORE, STARTER, PREMIUM, ULTIMATE)
A Gitaly-fürt lehetővé teszi a Git-tárolók replikálását több „meleg” Gitaly-csomópontra. Ez növeli a hibatűrést azáltal, hogy kiküszöböli az egyetlen hibapontot. A GitLab 13.3-as verziójában bevezetett módosítások a fürt összes Gitaly-csomópontjára sugározzák, de csak azok a Gitaly-csomópontok, amelyek egyetértenek az elsődleges csomóponttal, mentik a változtatásokat lemezre. Ha az összes replikacsomópont nem ért egyet, akkor a változtatásnak csak egy példánya kerül tárolásra a lemezen, egyetlen hibapontot hozva létre, amíg az aszinkron replikáció be nem fejeződik.
A többségi szavazás javítja a hibatűrést azáltal, hogy a módosítások lemezre mentése előtt megköveteli a csomópontok többségének (nem mindegyikének) beleegyezését. Ha ez a kapcsoló funkció engedélyezve van, az írásnak több csomóponton is sikeresnek kell lennie. Az eltérő csomópontok aszinkron replikációval automatikusan szinkronizálódnak azoktól a csomópontoktól, amelyek határozatképesek.
и .
Egyéni séma támogatása a JSON-ellenőrzéshez a Web IDE-ben
(PREMIUM, ULTIMATE, EZÜST, ARANY)
Azok a projektek, ahol az emberek JSON-ban vagy YAML-ben írnak konfigurációkat, gyakran ki vannak téve a problémáknak, mert könnyen elgépelhető és eltörhet valami. Lehetőség van ellenőrző eszközök írására a CI-folyamatban felmerülő problémák észlelésére, de a JSON-sémafájl használata hasznos lehet dokumentáció és tippek biztosításához.
A projekt résztvevői a tárukban meghatározhatják egy fájlban lévő egyéni séma elérési útját .gitlab/.gitlab-webide.yml, amely megadja a sémát és az ellenőrizendő fájlok elérési útját. Amikor betölt egy adott fájlt a webes IDE-be, további visszajelzéseket és ellenőrzéseket fog látni, amelyek segítenek a fájl létrehozásában.
и .
Az irányított aciklikus gráf (DAG) elágazási korlátja 50-re nőtt
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Ha szállítószalagot használ (Directed Acyclic Graph (DAG)), azt tapasztalhatja, hogy egy job legfeljebb 10 jobot határozhat meg needs:, túl durva. A 13.4-es verzióban az alapértelmezett korlát 10-ről 50-re nőtt, hogy lehetővé tegye a folyamatokban lévő jobok közötti kapcsolatok bonyolultabb hálózatait.
Ha Ön egy egyéni GitLab-példány rendszergazdája, ezt a korlátot még magasabbra emelheti egy kapcsoló funkció beállításával, bár ehhez hivatalos támogatást nem kínálunk.
и .
Javított viselkedés needs elmulasztott feladatokért
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Egyes esetekben egy folyamatban lévő kihagyott feladat tévesen tekinthető sikeresnek a következőben meghatározott függőségek esetén. needs, ami miatt a későbbi munkák futottak, aminek nem lett volna szabad megtörténnie. Ezt a viselkedést a 13.4-es verzió javította, és needs most már megfelelően kezeli az elmulasztott feladatok eseteit.
и .
Rögzítse az utolsó küldetésműterméket, hogy megakadályozza annak törlését
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab mostantól automatikusan zárolja az utolsó sikeres feladatot és folyamatműterméket minden aktív ágon, egyesítési kérelmen vagy címkén, hogy megakadályozza azok törlését a lejárat után. Könnyebbé válik agresszívebb lejárati szabályok felállítása a régi műtermékek megtisztításához. Ez segít csökkenteni a lemezterület-felhasználást, és biztosítja, hogy mindig legyen egy példánya a folyamatban lévő legújabb műtermékről.
и .
CI/CD útmutató a csővezeték-optimalizáláshoz
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A CI/CD-folyamat optimalizálása javíthatja a szállítási sebességet és pénzt takaríthat meg. Továbbfejlesztettük dokumentációnkat, hogy egy gyors útmutatót is tartalmazzon, amellyel a legtöbbet hozhatja ki a csővezetékek optimalizálása során.
и .
Tesztjelentés a teszt állapota szerint rendezve
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
egy egyszerű módja annak, hogy az összes teszt eredményét egy folyamatban tekintse meg. Nagy számú teszt esetén azonban a sikertelen tesztek megtalálása sokáig tarthat. További problémák, amelyek megnehezíthetik a jelentés használatát, többek között a hosszú nyomkövetési kimenetek görgetésének nehézségei és az idő nullára kerekítése az 1 másodpercnél rövidebb teszteknél. Most már alapértelmezés szerint a tesztjelentések rendezésekor a sikertelen teszteket először a jelentés elejére helyezi, majd a teszteket időtartam szerint rendezi. Ez megkönnyíti a hibák és a hosszú tesztek megtalálását. Ezenkívül a teszt időtartama ezredmásodpercben vagy másodpercben jelenik meg, így sokkal gyorsabban olvashatók, és a korábbi görgetési problémák is megoldódtak.
и .
A csomagnyilvántartásba feltöltött fájlok méretének korlátozása
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab csomag-nyilvántartásába feltölthető csomagfájlok mérete most korlátozott. Korlátozások kerültek bevezetésre a csomag-nyilvántartási teljesítmény optimalizálása és a visszaélések megelőzése érdekében. A korlátok a csomag formátumától függően változnak. A GitLab.com esetében a maximális fájlméret:
- Conan: 250 MB
- Méret: 3 GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3 GB
Az egyéni GitLab-példányok esetében az alapértelmezett értékek ugyanazok. A rendszergazda azonban frissítheti a korlátozásokat a használatával .
и .
A CI_JOB_TOKEN segítségével tegye közzé PyPI-csomagokat
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab PyPI-tárat használhatja Python-csomagok létrehozására, közzétételére és megosztására a forráskóddal és a CI/CD-folyamatokkal együtt. Korábban azonban nem tudott hitelesíteni a lerakat egy előre meghatározott környezeti változó használatával CI_JOB_TOKEN. Ennek eredményeként személyes hitelesítő adatait kellett használnia a PyPI-tárhely frissítéséhez, vagy esetleg úgy döntött, hogy egyáltalán nem használja a tárat.
Mostantól egyszerűbb a GitLab CI/CD használata PyPI-csomagok közzétételére és telepítésére egy előre meghatározott környezeti változó használatával CI_JOB_TOKEN.
и .
DAST szkenner profilok kérésre
(ULTIMATE, ARANY)
Az igény szerinti DAST vizsgálathoz , DAST szkennerprofilok hozzáadva. Kibővítik ezeknek a vizsgálatoknak a konfigurációs lehetőségeit, lehetővé téve, hogy gyorsan több profilt hozzon létre több vizsgálati típus lefedéséhez. A 13.4-es verzióban a bejáróprofil natívan tartalmaz egy bejáró időtúllépési beállítást, amely beállítja, hogy mennyi ideig fusson a DAST bejáró, amikor megpróbálja felfedezni a bejárt webhely összes oldalát. A profil tartalmaz egy célwebhely időtúllépési beállítást is, amellyel beállíthatja, hogy a bejárónak mennyi ideig várnia kell egy webhely elérhetővé válására, mielőtt megszakítja a feltérképezést, ha a webhely nem válaszol 200-as vagy 300-as állapotkóddal. Ahogy folyamatosan fejlesztjük, ez a funkció hozzáadva a lapolvasó profilhoz a jövőbeli kiadásokban; további konfigurációs paraméterek kerülnek hozzáadásra.
и .
Egy egyszerű átirányítási konfigurációs fájl a GitLab oldalakhoz
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Ha GitLab Pages-t használ, és jobban szeretné kezelni az URL-módosításokat, akkor észrevehette, hogy a GitLab Pages webhelyén nem lehetett kezelni az átirányításokat. A GitLab mostantól lehetővé teszi a szabályok konfigurálását, amelyek átirányítják az egyik URL-t a másikra a Pages-webhelyen egy konfigurációs fájl hozzáadásával a tárhoz. Ez a funkció Kevin Barnett (), a mi Eric Eastwoodunk () és a GitLab csapatok. Köszönöm mindenkinek a hozzájárulását.
и .
A GitLab által kezelt Terraform állapot
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A Terraform állapot korábbi verzióihoz való hozzáférés szükséges mind a megfeleléshez, mind a szükség esetén a hibakereséshez. A GitLab által kezelt Terraform állapot verziószámításának támogatása a GitLab 13.4-től kezdve biztosított. A verziószámozás automatikusan engedélyezve van az új Terraform állapotfájlokhoz. A meglévő Terraform állapotfájlok lesznek egy későbbi kiadásban.
и .
A fontos incidensről szóló értesítés részletei
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Az incidensek feldolgozásakor könnyen meg kell tudnia állapítani, mennyi ideig volt nyitva egy riasztás, és hányszor váltották ki az eseményt. Ezek a részletek gyakran kritikus fontosságúak az ügyfélre gyakorolt hatás meghatározásában, és annak meghatározásában, hogy a csapatnak mire kell először foglalkoznia. Az új Incident részletei panelen megjelenítjük a riasztás kezdési időpontját, az események számát és az eredeti riasztásra mutató hivatkozást. Ez az információ a riasztásokból generált incidenseknél érhető el.
и .
Az esemény súlyossági paraméterének beállítása és szerkesztése
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
Az incidens súlyossága dimenzió lehetővé teszi a reagálók és az érintettek számára, hogy meghatározzák a kimaradás hatását, valamint a válaszadás módját és sürgősségét. Mivel csapata megosztja az eredményeket az incidensek megoldása és helyreállítása során, módosíthatja ezt a beállítást. Mostantól szerkesztheti az események súlyosságát az Incidens részletei oldal jobb oldalsávjában, és a súlyosság megjelenik az események listájában.
и .
Tárolóhálózati biztonsági szabályok létrehozása, szerkesztése és törlése
(ULTIMATE, ARANY)
A Container Network Security Rule Editor ezen továbbfejlesztése lehetővé teszi a felhasználók számára, hogy egyszerűen létrehozzák, szerkeszthessék és töröljék szabályaikat közvetlenül a GitLab felhasználói felületéről. A szerkesztő funkciók közé tartozik .yaml tapasztalt felhasználók számára, valamint egy szabályszerkesztő intuitív kezelőfelülettel azoknak, akik újak a hálózati szabályokban. Az új szabálykezelési lehetőségeket a rovatban találja Biztonság és megfelelőség > Fenyegetéskezelés > Szabályok (Biztonság és megfelelőség > Fenyegetéskezelés > Irányelvek).
и .
Azure blob tárolás támogatása
(CORE, STARTER, PREMIUM, ULTIMATE, INGYENES, BRONZ, EZÜST, ARANY)
A GitLab és a GitLab Runner is támogatja , ami megkönnyíti a GitLab-szolgáltatások futtatását az Azure-ban.
A GitLab-példányok minden típusú objektumtárolóhoz támogatják az Azure-t, beleértve az LFS-fájlokat, CI-műtermékeket és . Az Azure Blob Storage beállításához kövesse a telepítési utasításokat vagy .
A GitLab-feladat-feldolgozók az Azure-t is támogatják a tároláshoz . Az Azure Storage a szakasz segítségével konfigurálható .
и .
Omnibus ARM64 csomagok Ubuntu és OpenSUSE számára
(CORE, STARTER, PREMIUM, ULTIMATE)
A GitLab 64 bites ARM architektúrán történő futtatása iránti növekvő igényre válaszul örömmel jelentjük be a hivatalos ARM64 Ubuntu 20.04 Omnibus csomag elérhetőségét. Óriási köszönet Zitai Chennek és Guillaume Gardetnek óriási hozzájárulásukért – az egyesülési kérelmük kulcsszerepet játszott ebben!
Az Ubuntu 20.04 csomag letöltéséhez és telepítéséhez látogasson el a mi oldalunkra és válassza ki Ubuntu.
и .
Intelligens kártya hitelesítés támogatása a GitLab Helm diagramhoz
(PREMIUM, ULTIMATE)
Az intelligens kártyák, például a Common Access Cards (CAC) mostantól használhatók a Helm diagramon keresztül telepített GitLab-példányok hitelesítésére. Az intelligens kártyák hitelesítése egy helyi adatbázisban történik X.509 tanúsítványok használatával. Ezzel az intelligenskártya-támogatás a Helm-diagrammal összhangban van az Omnibus-telepítésekben elérhető intelligenskártya-támogatással.
и .
A részletes kiadási megjegyzések és a frissítési/telepítési utasítások az eredeti angol bejegyzésben olvashatók: .
Az angol nyelvű fordításon dolgoztunk , , и .
Forrás: will.com