Megérkezett a 13.4-es kiadás, amely tartalmaz egy HashiCorp tárolót a CI változókhoz, Kubernetes ügynököt és biztonsági központot, valamint kapcsolható funkciókat a Starterben.
A GitLabnál mindig azon gondolkodunk, hogyan segíthetjük a felhasználókat a kockázatok csökkentésében, a hatékonyság növelésében és a szállítási sebesség javításában a kedvenc platformjukon. Ebben a hónapban számos hasznos újdonságot adtunk hozzá, amelyek bővítik a biztonsági lehetőségeket, csökkentik a sebezhetőségeket, növelik a hatékonyságot, egyszerűsítik a GitLab használatát, és segítik csapatát abban, hogy még gyorsabban szállítsanak funkciókat. Reméljük, hogy az alapvető funkciók hasznosak lesznek az Ön számára, valamint 53 másik új funkcióis hozzá lett adva ebben a kiadásban.
Kiterjesztett biztonsági lehetőségek
Minden hónapban próbálunk néhány új funkciót hozzáadni a GitLab DevSecOps-hoz, és ez a kiadás sem kivétel. a build és telepítési folyamatok során. Ezenkívül azok a szervezetek, amelyek szeretnék fenntartani a kódtelepítési feladatok megosztottságát, mostantól . Ez a szerep megfelel és lehetővé teszi a merge kérelmek megerősítését (a GitLab orosz nyelvű verziójában „olvasási kérések”), valamint a kód telepítését védett környezetekbe, anélkül, hogy hozzáférést biztosítanánk a kód módosításához.
Egy újabb módja a kockázatok csökkentésének az új . Az üzemeltetők Kubernetes klasztereket telepíthetnek GitLabból anélkül, hogy az egész internethez hozzáférést kellene biztosítaniuk a klaszterükhöz. Ezenkívül automatikus verziókezelést is bevezetünk az új Terraform állapotfájlokhoz, a megfelelőségi követelmények és az egyszerű hibakeresés támogatására. Végül is a biztonsági irányítópult a példányban átalakult egy sebezhetőségi jelentésekkel és biztonsági beállításokkal.
Kényelmesebb és hatékonyabb munka a GitLabban
Javítottuk a globális keresésünket, mostantól , amely lehetővé teszi a legutóbbi jegyek, csoportok, projektek, beállítások és súgó részletek egyszerű elérését. Örömmel jelentjük be, hogy a GitLab Pages-en a webhelyen belüli egyes oldalak és mappák átirányítására, amely lehetővé teszi a felhasználók számára, hogy hatékonyabban telepítsék webhelyeiket. Aki pedig részletesebb információkat szeretne a telepítésről, annak ez a kiadás lehetőséget biztosít !
Nyílt forráskódú letétek
Bemutatjuk , amelyet hozzáadott . A módosított kód egység tesztjei által megadott lefedettség feljegyzései egyértelmű képet adnak a fejlesztőknek a kódlefedettségről a felülvizsgálat során; ez az információ segít felgyorsítani a felülvizsgálatot és csökkenteni az új kód egyesítésére és telepítésére fordított időt. Továbbá mi és tervezzük .
Ez még csak a kezdet!
Mint mindig, a havi összehúszban túl kevés hely áll rendelkezésre, és a 13.4-es kiadásban nagyon sok klassz funkció van. Íme még néhány:
- .
Ha előre szeretné tudni, mi vár Önre a következő kiadásban, nézze meg .
.
ez a hónap —
Fabio jelentős be. — egy olyan funkciót, amelyet a GitLab közösség nagyon régóta várt. Ez valóban fontos hozzájárulás, nem triviális változtatásokkal, amelyek folyamatos együttműködést igényeltek a GitLab csapat tagjaival, és sok területet érintettek a projektben, például az UX-t, a frontendet és a hátteret.
A GitLab 13.4-es kiadásának főbb funkciói
Használja a HashiCorp Vault kulcsokat a CI feladatokban
(PREMIUM, ULTIMATE, SILVER, GOLD)
A 12.10-es kiadásban a GitLab bemutatta a lehetőséget, hogy kulcsokat kapjon és adjon át a CI feladatok során a GitLab futtatóval. Most bővítjük , új szintaxist adva hozzá titkok a fájlba .gitlab-ci.yml. Ez megkönnyíti a HashiCorp tároló beállítását és használatát a GitLabbal.
és .
Bemutatjuk a GitLab Kubernetes ügynököt
(PREMIUM, ULTIMATE)
A GitLab Kubernetes integráció már régen lehetővé teszi a Kubernetes klaszterek telepítését anélkül, hogy manuálisan kellene konfigurálni. Sok felhasználónak tetszik ennek a kombinációnak az egyszerűsége, míg mások néhány nehézséggel szembesültek. Az aktuális integrációhoz a klaszterednek hozzáférhetőnek kell lennie az interneten, hogy a GitLab hozzáférhessen. Sok szervezet számára ez nem lehetséges, mivel biztonsági, megfelelőségi vagy szabályozási okokból korlátozzák a klaszterekhez való hozzáférést. Ezeknek a korlátozásoknak a megkerüléséhez a felhasználóknak saját eszközöket kellett létrehozniuk a GitLab felett, különben nem tudták kihasználni ezt a lehetőséget.
Ma bemutatjuk a GitLab Kubernetes Ügynököt – egy új módot a Kubernetes klasztereken való telepítéshez. Az ügynök a klaszteredben működik, így nem kell megnyitnod azt az egész internet számára. Az ügynök koordinálja a telepítést, és új változtatásokat kér a GitLab-tól, nem pedig a GitLab küldi az frissítéseket a klaszterre. Függetlenül attól, hogy melyik GitOps módszert használod, a GitLab megfelelő lesz számodra.
Felhívjuk figyelmed, hogy ez az ügynök első kiadása. Jelenleg a GitLab Kubernetes Ügynök körüli beállításra és telepítési menedzsmentre helyeztük a hangsúlyt kódon keresztül. Néhány meglévő Kubernetes integrációs funkció, mint például a telepítési táblák és a GitLab által kezelt alkalmazások, még nem támogatott. , hogy ezek a funkciók a jövőbeli kiadásokban kerülnek majd be az ügynökbe, valamint új, biztonságra és megfelelőségre orientált integrációk.
és .
Adjon felhasználóknak telepítési engedélyt kódhozzáférés nélkül
(PREMIUM, ULTIMATE, SILVER, GOLD)
Korábban a GitLab engedélyezési rendszere nem tette lehetővé a feladatok szakszerű elosztását a csapatában a fejlesztők és a telepítéssel foglalkozók között. A GitLab 13.4-es kiadásával lehetősége van arra, hogy bizonyos felhasználóknak engedélyezze a merge kérések jóváhagyását a telepítéshez, valamint a tényleges kódtelepítést olyan emberek számára, akik nem írnak kódot, anélkül, hogy a karbantartói (a GitLab orosz lokalizációjában „fenntartó”) jogokat biztosítana számukra.
és .
Biztonsági központ
(ULTIMATE, GOLD)
Korábban az instanciaszintű sebezhetőségkezelés korlátozott volt a funkcionalitás és a rugalmasság szempontjából. A felület egyetlen oldalt tartalmazott, amely összevonja a sebezhetőségek részleteit, a metrikák grafikonjait és a beállításokat. Nem volt sok hely e funkciók fejlődésére vagy más biztonsági eszközök használatára.
Alapvető változtatásokat hajtottunk végre a biztonság kezelésében és átláthatóságában a GitLab-ban. Az instanciaszintű biztonsági panel egy igazi biztonsági központtá alakult. A legnagyobb változás a menü új struktúrájának bevezetése: egyetlen oldal helyett most külön láthatja a biztonsági vezérlőpultot, a sebezhetőségi jelentést és a beállítások szakaszát. Bár a funkcionalitás nem változott, a részekre bontás lehetővé teszi ezen szakasz javítását, ami máskülönben nehezen lenne megvalósítható. Ez egyben alapot teremt a jövőbeni biztonsággal kapcsolatos további lehetőségek hozzáadásához is.
A sebezhetőségi jelentéshez külön szakasz most több helyet biztosít a lényeges részletek megjelenítésére. Itt találhatók a jelenleg a projekten belüli sebezhetőségek. A sebezhetőségi metrikák widgetjeinek külön szakaszba helyezése egy kényelmes biztonsági vezérlőpultot teremt. Most ez a jövőbeli vizualizációk vászna — nem csak a sebezhetőségek kezelésére, hanem bármilyen biztonsággal kapcsolatos metrikára is. Végül, a különálló beállítási terület közös teret teremt az instanciaszintű összes biztonsági beállításhoz, nemcsak a sebezhetőségek kezeléséhez.
és .
Az átkapcsolható funkciók most a GitLab Starterben találhatók
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
A GitLab 11.4 verziójában jelent meg . A 12.2 verzióban bevezettük a számukra a stratégiákat és , a 13.1 verzióban pedig hozzáadtuk és különböző környezetek számára.
Korábban idén a GitLab kötelezettséget vállalt nyílt forráskódba. Ebben a kiadásban befejeztük az átkapcsolható funkciók áthelyezését a Starter tervbe, és folytatni fogjuk az áttelepítésüket a Core-ba a . Örömmel biztosítjuk ezt a lehetőséget több felhasználó számára, és szeretnénk tudni, hogyan tervezik használni őket.
és .
Gyors navigáció a keresősorból
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Néha, amikor a GitLabban navigál, közvetlenül egy adott projekthez szeretne ugrani, nem pedig az eredmények oldalára.
A globális keresési panele segítségével gyorsan hozzáférhet a legutóbbi jegyzetekhez, csoportokhoz, projektekhez, beállításokhoz és a súgó szakaszaihoz. Még használhatja a billentyűparancsot /, hogy a kurzort a keresési panelre helyezze, így még hatékonyabban navigálhat a GitLabban!
és .
A kódlefedettség megjelenítése a merge kérések diffjeiben
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A merge kérés átnézésekor nehéz lehet meghatározni, hogy a módosított kódot egységtesztek fedik-e. A felülvizsgálók esetleg a teljes lefedettségre támaszkodhatnak, és megkövetelhetik annak növelését a merge kérés jóváhagyása előtt. Ez rendszertelen megközelítést eredményezhet a tesztírásban, ami valójában nem javítja a kód minőségét vagy a tesztekkel való lefedettségét.
Most, amikor a merge kérés diffjét nézi, szemléletes megjelenítést lát a kódlefedettségről. Az új jelölések lehetővé teszik, hogy gyorsan megértse, hogy a módosított kódot egységteszt fedi-e, ami segít felgyorsítani a kód átnézését és az új kódok beolvasztásának és telepítésének idejét.
Köszönöm és a Siemensnek ezért a funkcióért!
és .
Több környezet és projekt a környezetek panelen
(PREMIUM, ULTIMATE, SILVER, GOLD)
A GitLab 12.5-ös kiadása óta a nyomon követheti a környezetek állapotát, de nem több mint hét környezetet három projektben. Ezt a panelt javítottuk a 13.4-es kiadásban, azáltal, hogy oldalra bontottuk segítve ezzel a nagyobb volumenű környezetek fenntartását és kezelését. Most több környezetet láthat több projektben.
és .
A GitLab átvette a GitLab Terraform provider kezelését
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nemrégiben és tervezzük . Az utolsó hónapban 21 merge kérdést fogadtunk el és 31 jegyzetet zártunk le, beleértve néhány régóta fennálló hibát és hiányzó funkciót, mint például . További információkat tudhat meg a GitLab Terraform provider-rel kapcsolatban a A GitLab Terraform provider dokumentációja
és .
Фаззинг-тестирование API со спецификациями OpenAPI или HAR-файлом
(ULTIMATE, GOLD)
Az API-hoz kapcsolódó fuzzing tesztelés egy kiváló módszer a webalkalmazásokban és API-kban előforduló hibák és sebezhetőségek keresésére, amelyeket más szkennerek és tesztelési módszerek esetleg figyelmen kívül hagyhatnak.
A fuzzing API tesztelése a GitLabban lehetővé teszi vagy az alkalmazásodhoz, majd automatikusan véletlenszerű bemeneteket generál, amelyek a szélsőséges esetek ellenőrzésére és hibák keresésére szolgálnak. Az eredmények azonnal megjelennek a folyamatod keretein belül.
Ez az első kiadásunk az API fuzzing teszteléséről, és örömmel várjuk véleményedet. A fuzzing teszteléshez még , amelyeket a funkció kiadására alapozunk.
és .
Új grafikonok előnézete a metrikapanelen
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Korábban a metrikapanelen grafikon létrehozása nem volt egyszerű feladat. Miután létrehoztad a metrikát a panel YAML-fájljában, módosításokat kellett végrehajtanod master, anélkül, hogy ellenőrizhetted volna, hogy azonnal létrehozott grafikon pontosan úgy működik-e, ahogy azt szeretnéd. E kiadástól kezdve előnézetet kaphatsz a grafikon létrehozása közben, így betekintést nyerhetsz az eredménybe, mielőtt a módosításokat a panel YAML-fájljába küldenéd.
és .
A kód tesztelési lefedettségi adatai a csoport összes projektjében
(PREMIUM, ULTIMATE, SILVER, GOLD)
Amikor sok projektet kezelsz a GitLabban, egyetlen információforrásra van szükséged, hogy nyomon kövesd, hogyan változik az idő múlásával a kód lefedettsége az összes projektben. Korábban ennek az információnak a megjelenítése fárasztó és időigényes manuális munkát igényelt: minden projektből le kellett töltened a kód tesztelési lefedettségi adatait, és azokat egy táblázatba kellett egyesítened.
A 13.4-es kiadásban lehetőség nyílt könnyen és gyorsan összegyűjteni a .csv fájlba az összes csoportos projekt kód lefedettségi adatait vagy projektválasztás adatait. Ez a funkció egy MVC, amit követni fog a lehetőség .
és .
Új nyelvek támogatása a teljes fuzzing teszteléshez
(ULTIMATE, GOLD)
Ez a kiadás több új nyelvet kínál a teljes lefedettségre irányuló fuzzing teszteléshez.
Most már értékelheti a fuzzing tesztelés összes lehetőségét Java, Rust és Swift alkalmazásaiban, és felfedezheti azokat a hibákat és sebezhetőségeket, amelyeket más szkennerek és tesztelési módszerek figyelmen kívül hagyhatnak.
és .
Értesítések a környezetek főoldalán
(PREMIUM, ULTIMATE, SILVER, GOLD)
A környezetek oldala a környezetek összesített állapotát mutatja. Ebben a kiadásban javítottuk ezt az oldalt, értesítések megjelenítésével. Az aktivált értesítések a környezetek állapotával együtt segítenek Önnek gyorsabban reagálni a felmerülő helyzetekre.
és .
A belső pipeline-ok most elindíthatják a saját belső pipeline-aikat
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Olyan belső pipeline-ok használatakor, amelyek képesek új pipeline-okat indítani a gyermek pipeline-ok belsejében, hasznos lehet egy további szint mélység, ha rugalmasan szeretne változó számú pipeline-t generálni.
Korábban, amikor belső pipeline-okat használt, minden gyermek pipeline-nak szüksége volt egy trigger feladatra, amit manuálisan kellett megadni a szülő pipeline-ban. Most belső pipeline-okat hozhat létre, amelyek dinamikusan indítják el a szükséges számú új belső pipeline-t. Például, ha monorepozitóriuma van, dinamikusan generálhatja az első belső pipeline-t, amely önállóan hoz létre annyi új pipeline-t, amennyire a ágon bekövetkező változások alapján szükség van.
és .
Javított navigáció a szülő és belső pipeline-ok között
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A szülő és belső pipeline-ok közötti navigáció korábban nem volt túl kényelmes - sok kattintásra volt szükség ahhoz, hogy eljuthasson a kívánt pipeline-hoz. Továbbá nehéz volt megérteni, hogy melyik feladat indította el ezt a pipeline-t. Most sokkal egyszerűbb lesz látni a kapcsolatokat a szülő és a belső pipeline-ok között.
és .
Párhuzamos mátrixes feladatok a releváns változókat mutatják a feladat nevében
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ha használta a , észrevehette, hogy nehéz volt meghatározni, melyik mátrixos változót használták egy adott feladatnál, mivel a feladatnevek úgy néztek ki, mint matrix 1/4A 13.4-es kiadásban a feladat neve helyett releváns változóértékeket fog látni, amelyeket ebben a feladatban használtak. Például, ha a célja a x86 architektúrához való hibakeresés, akkor a feladat neve mátrix: hibakeresés x86.
és .
Egyéb fejlesztések a GitLab 13.4-ben
Atlassian fiók csatlakoztatása
(CORE, STARTER, PREMIUM, ULTIMATE)
A GitLab felhasználói most csatlakoztathatják GitLab fiókjukat az Atlassian Cloud fiókjukhoz. Ez lehetővé teszi, hogy Atlassian hitelesítő adatokkal jelentkezzenek be a GitLabba, és alapot teremt a jövőbeni fejlesztésekhez az integrációban valamint más Atlassian-termékekkel.
és .
Minden merge commit listájának exportálása
(ULTIMATE, GOLD)
Azoknak a szervezeteknek, amelyek a megfelelőség biztosítására törekednek, szükségük van arra, hogy az auditorok számára átfogó képet nyújtsanak a bármely konkrét változtatáshoz kapcsolódó összetevőkről a termelésben. A GitLab keretein belül ez annyit jelent, hogy mindent egy helyen kell összegyűjteni: merge kérések, jegyek, pipeline-ok, biztonsági szkennelések és egyéb commit adatok. Eddig vagy manuálisan kellett összegyűjteni ezeket a GitLabban, vagy saját eszközöket kellett beállítani az információk gyűjtésére, ami nem volt túlságosan hatékony.
Mostantól programozottan gyűjtheti és exportálhatja ezeket az adatokat az auditigények kielégítése vagy egyéb elemzések elvégzése érdekében. A csoporti merge commitok listájának exportálásához lépjen a és kattintson a gombra Minden merge commit listája. A kapott fájl tartalmazni fogja az összes merge commitot, a szerzőjüket, a kapcsolódó merge kérés azonosítóját, csoportot, projektet, megerősítéseket és egyéb információkat.
és .
A személyes hozzáférési tokenek listázása és kezelése az API-n keresztül
(ULTIMATE, GOLD)
A GitLab névtartományhoz való hozzáférés kezelése fontos része a megfelelőségi tevékenységeknek. A minimális jogosultságok elvétől kezdve a hozzáférés időzített letiltásáig több követelmény is kapcsolódhat a GitLab személyes hozzáférési tokenjeihez. Annak érdekében, hogy könnyebben karbantarthassa és kezelhesse ezeket a felhasználói hitelesítési adatokat a névtartományában, lehetőséget biztosítottunk a személyes hozzáférési tokenek listájának exportálására, opcionálisan. API-n keresztül.
A GitLab API-jában végrehajtott fejlesztések lehetővé teszik a felhasználók számára, hogy kilistázzák és visszavonják saját személyes hozzáférési tokenjeiket, míg az adminisztrátorok a felhasználók tokenjeit is kilistázhatják és visszavonhatják. Mostantól az adminisztrátorok könnyebben láthatják, kik férnek hozzá a névtérhez, döntéseket hozhatnak a hozzáférés megadásáról a felhasználói adatok alapján, valamint visszavonhatják azokat a személyes hozzáférési tokeneket, amelyek esetleg kompromittálódtak vagy amelyek túllépnek a vállalati hozzáféréskezelési irányelveken.
és .
Kapcsolódó jegyek és egyéb funkciók mostantól a GitLab Core-ban
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Néhány hónappal ezelőtt bejelentettük a tervünket . Az ígéretünk betartása érdekében , és (a GitLab orosz lokalizációjában „megbeszélés táblája”) elérhető a Core tervben. Ez csak a „kapcsolódik” típusú kapcsolatokra vonatkozik, míg a „blokkol” és a „blokkolva van” típusú kapcsolatok a fizetős tervekben maradnak.
és .
A forrás ágazat nevének megjelenítése a merge request oldalsávján
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A kódváltozások, megbeszélések és a merge request biztonsági mentése során gyakran kívánatos helyi checkoutot készíteni az ágazatról a mélyebb áttekintéshez. Azonban a merge request leírásának bővítése során egyre nehezebb megtalálni az ágat, és távolabb kell lapozni az oldalon.
Hozzáadtuk az ágat a merge request oldalsávjához, így ez bármikor elérhetővé válik, és megszünteti a szükségességet, hogy az egész oldalt átlapozzuk. Az ágra mutató linkhez hasonlóan a forráshoz tartozó részben kényelmes „másolás” gomb található.
Köszönöm a funkció fejlesztéséhez nyújtott jelentős hozzájárulásáért!
és .
A merge request diffeiben lévő összehúzott fájlok jelzése
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A merge request that adds changes to multiple files sometimes collapses the diffs of large files to improve display performance. When this happens, a file can be accidentally missed during review, especially in merge requests with many files. Starting from version 13.4, merge requests will highlight diffs containing collapsed files, ensuring that you don’t overlook these files during the code review process. For even greater clarity, we plan to add highlighting for these files in a future release. Stay tuned for updates in .
és .
Warning of collapsed files in the diff of a merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
In the diff section of merge requests, large files are collapsed for performance enhancements. However, during code review, some files may be missed when the reviewer scrolls through the file list, as all large files are collapsed.
We have added a visible warning at the top of the merge request diff page to inform users that there is a collapsed file in this section. This way, you won’t miss any changes in the merge request during your review.
és .
Automatic recovery of the Gitaly cluster repository
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Previously, when the primary node of the Gitaly cluster went down, repositories on that node were marked as read-only. This prevented data loss in situations where changes had not yet been replicated on that node. When the node was reconnected, GitLab did not recover automatically, and administrators had to manually start the synchronization process or accept data loss. Other situations, such as a failed replication job on a secondary node, could also lead to outdated or read-only repositories. In this case, the repository would remain outdated until the next write operation triggered a replication job.
To solve this problem Most már automatizált feladatot tervez a replikációhoz, amikor elavult tárolót talál egy noden és a legújabb verziót egy másikon. Ez a replikációs feladat automatikusan frissíti a tárolót, megszüntetve ezzel az adatok manuális helyreállításának szükségességét. Az automatikus helyreállítás gyorsan hozza friss állapotba a másodlagos nodokat, ha a replikációs feladat nem sikerül, ahelyett, hogy várni kellene a következő írási műveletre. Mivel a Gilaly klaszterek sok tárolót tárolnak, ez jelentősen csökkenti az adminisztrátorok és a megbízhatósági mérnökök által az adatok helyreállítására fordított időt hiba esetén.
Ezen kívül az automatikus javítás elindítja a tárolók replikációját bármely új Gitaly nodán, amelyet hozzáadtak a klaszterhez, megszüntetve ezzel a manuális munkát az új nodák hozzáadásakor.
és .
Jelölje meg a to-do feladatot teljesítettnek a dizájn oldalon
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab hatékony kommunikációja a to-do feladatlistákon alapul. Ha megemlítettek egy hozzászólásban, rendkívül fontos, hogy legyen lehetősége áttérni a feladatra, és vagy elkezdeni a munkát, vagy megjelölni azt már teljesítettnek. Az is fontos, hogy feladatot adhasson magának, amikor arra van szüksége, hogy dolgozzon valamin, vagy később visszatérjen hozzá.
Korábban nem lehetett feladatokat hozzáadni vagy azokat teljesítettnek jelölni a dizájnokkal való munka során. Ez súlyosan csökkentette a termékcsapatok közötti kommunikáció hatékonyságát, mivel a to-do feladatok kulcsfontosságú elemei a GitLab munkafolyamatának.
A 13.4-es kiadásban a dizájnok utolérik a ticket hozzászólásokat a feladatok használatában, ezáltal a munkájuk egységesebb és hatékonyabb lesz.
és .
Fokozott hibaelhárítási útmutató a CI/CD számára
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Javítottuk a GitLab CI/CD hibaelhárítási útmutatóját, hozzáadva további információkat a gyakori problémákról, amelyekkel találkozhat. Reméljük, hogy a fejlettebb dokumentáció értékes forrást jelent, amely segít Önnek a GitLab CI/CD gyors és egyszerű beállításában és elindításában.
és .
A merge request is no longer dropped from the merge queue.
(PREMIUM, ULTIMATE, SILVER, GOLD)
Previously, merge requests could accidentally fall out of the merge queue due to late comments. If a merge request was already in the queue and someone added a comment that created a new unresolved discussion, the merge request was considered unsuitable for merging and was dropped from the queue. Now, after a merge request is added to the merge queue, new comments can be added without fear of disrupting the merging process.
és .
Display of code coverage value for a job in the merge request
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Developers should be able to see the code coverage value after the pipeline finishes — even in complex scenarios, like when the pipeline runs multiple jobs that need parsing to calculate the coverage value. Previously, the merge request widget only showed the average of these values, meaning you had to navigate to the job page and back to the merge request to get the intermediate coverage values. To save your time and eliminate these extra steps, we’ve made the widget display the average coverage, its changes between the target and source branches, and a tooltip that shows the coverage value for each job based on which the average was calculated.
és .
Removing packages from the package registry while viewing the group
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
The GitLab package registry is a place to store and distribute packages in various formats. When your project or group has many packages, you need to quickly identify unused packages and remove them to prevent people from downloading them. You can remove packages from your registry via or through the package registry user interface. However, until now you could not remove packages while viewing the group through the user interface. As a result, you had to remove extra packages separately for each project, which was inefficient.
Now you can remove packages while viewing the group package registry. Simply go to the group package registry page, filter the packages by name, and delete all the unnecessary ones.
és .
A Conan csomagok projekt szintű méretezése
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A Conan tárolót használhatja a GitLab-on C/C++ függőségek közzétételére és terjesztésére. Korábban a csomagokat csak példány szinten lehetett méretezni, mivel a Conan csomagnév maximum 51 karakterből állhatott. Ha például egy almappából szeretett volna csomagot közzétenni, gitlab-org/ci-cd/package-stage/feature-testing/conan, ez szinte lehetetlen volt.
Most a Conan csomagokat projekt szintre tudja méretezni, amely lehetővé teszi a projektek függőségeinek könnyű közzétételét és terjesztését.
és .
Új csomagkezelők és nyelvek támogatása a függőségek vizsgálatához
(ULTIMATE, GOLD)
Örömmel jelentjük be, hogy a C, C++, C# és .Net nyelvekkel kapcsolatos projektekhez, amelyek NuGet 4.9+ vagy Conan csomagkezelőket használnak, hozzáadtuk a függőségek vizsgálatát a támogatott nyelvek és keretrendszerek listájához. . Most a függőségek vizsgálatát a Secure szakasz részeként is be lehet illeszteni, hogy ellenőrizze a csomagkezelőkön keresztül hozzáadott ismert sebezhetőségeket. A talált sebezhetőségek megjelennek az Ön merge kérésében a veszélyességi szintjükkel együtt, így tudni fogja, hogy a merge végrehajtása előtt milyen kockázatot jelent az új függőség. A projektjét úgy is konfigurálhatja, hogy megkövetelje a kritikus (Critical), magas (High) vagy ismeretlen (Unknown) kockázati szintű sebezhetőségekkel rendelkező függőségekhez.
és .
Értesítések a merge kérés ‘Merge When Pipeline Succeeds’ beállításának megváltoztatásakor
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Korábban amikor a merge kérés beállítását megadta Merge, amikor a pipeline befejeződik (Merge When Pipeline Succeeds, MWPS), nem küldtek e-mail értesítést. Önnek manuálisan kellett ellenőriznie a státuszt, vagy várnia kellett az értesítést a merge végrehajtásáról. Ebben a kiadásban örömmel mutatjuk be a felhasználói hozzájárulást , aki megoldotta ezt a problémát azzal, hogy automatikus értesítést küldött mindenkinek, aki feliratkozott a merge kérésre, amikor a felülvizsgáló MWPS-ra változtatja a merge beállítást.
és .
EKS klaszterek létrehozása felhasználó által megadott Kubernetes verzióval
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab felhasználói mostantól választhatják ki a Kubernetes verzióját, amelyet az EKS kínál, 1.14–1.17 közötti verziók közül választhatnak.
és .
Incidensek létrehozása mint jegytípusok
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nem minden felmerülő probléma indít azonnal értesítések küldését: a felhasználók hibákról számolnak be, míg a csapattagok a teljesítményproblémákat elemzik. Mostantól az incidensek jegytípusnak számítanak, így csapataid gyorsan létrehozhatják azokat a megszokott munkafolyamat keretein belül. Kattints Új feladat bármely helyről a GitLabban, és a mezőben Típus válaszd ki Incidens.
és .
GitLab értesítések említése Markdownban
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Javítottuk a GitLab értesítéseket, egy új említési típust adtunk hozzá kifejezetten számukra a GitLab-változatú Markdownon, ami megkönnyíti az értesítések megosztását és említését. Használj ^alert#1234, hogy említsd meg az értesítést bármely Markdown formázással ellátott mezőben: incidensekben, jegyekben vagy merge-keresésekben. Ez segít az értesítésekből létrejövő feladatok azonosításában is, nem pedig a jegyekből vagy merge-keresésekből.
és .
Az incidens értesítések terhelésének megtekintése
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Az értesítés leírása olyan információkat tartalmaz, amelyek kritikusak a hibák diagnosztizálásához és helyreállításához, és ennek az információnak könnyen hozzáférhetőnek kell lennie, hogy ne kelljen eszközöket vagy lapokat váltogatni az incidens megoldásakor. Az értesítésekből létrehozott incidensek az értesítés teljes leírását mutatják a Értesítés részletei.
75%-kal gyorsabb kiterjesztett keresés
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
A GitLab, mint egységes alkalmazás, egyedülálló lehetőséget biztosít, hogy a tartalom keresése az egész DevOps munkafolyamatban gyors legyen. A GitLab 13.4-es verziójában a kiterjesztett keresés 75%-kal gyorsabb eredményeket ad, amikor , mint a GitLab.com-on.
és .
A távoli projektek megtekintése az adminisztrátorok számára
(CORE, STARTER, PREMIUM, ULTIMATE)
A projekt törlésének elhalasztásának lehetősége Korábban azonban nem volt lehetőség arra, hogy egy helyen lássuk az összes törlésre váró projektet. Most a GitLab felhasználói instanciák adminisztrátorai egy helyen tekinthetik meg az összes törlésre váró projektet, együtt a könnyű visszaállításhoz szükséges gombokkal.
Ez a funkció lehetővé teszi az adminisztrátorok számára, hogy jobban ellenőrizzék a projektek törlését, összegyűjtve minden szükséges információt egy helyen, és lehetőséget biztosítva a nem kívánt törlési műveletek visszavonására.
Köszönöm köszönjük ezt a funkciót!
és .
Az API támogatást kapott a csoportos push szabályokhoz
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Korábban a csoportos push szabályokat csak úgy lehetett beállítani, hogy egyenként látogattuk meg minden csoportot a GitLab felhasználói felületén, és alkalmaztuk ezeket a szabályokat. Mostantól ezeket a szabályokat az API-n keresztül kezelheti, támogathatja a saját eszközeit és automatizálhatja a GitLab-ot.
és .
Hozzáférési személyes tokenek visszavonása a saját kezelt hitelesítő tárolónál
(ULTIMATE)
információt nyújt az adminisztrátorok számára a GitLab felhasználóik hitelesítő adataik kezeléséhez. Mivel a megfelelőségi irányelvekre összpontosító szervezetek eltérő szigorúsággal rendelkeznek a hitelesítő adataik kezelésében, hozzáadtunk egy gombot, amely lehetővé teszi az adminisztrátorok számára a felhasználó személyes hozzáférési tokenjének (PAT) visszavonását. Most az adminisztrátorok könnyen visszavonhatják a potenciálisan kompromittált PAT-okat. Ez a funkció hasznos lehet azoknak a szervezeteknek, amelyek rugalmasabb lehetőségekre vágynak a követelmények érvényesítésére, hogy minimalizálják a felhasználóik figyelmének elterelését.
és .
Statikus webhely szerkesztő konfigurációs fájlja
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab 13.4-ben bemutatunk egy új módot a statikus webhely szerkesztő beállítására. Bár a konfigurációs fájl ebben a kiadásban nem tárol és nem kap semmilyen paramétert, megalapozza a szerkesztő viselkedésének jövőbeli beállítását. A következő kiadásokban hozzáadunk a fájlhoz .gitlab/static-site-editor.yml a beállításokhoz szükséges paramétereket , ahol , a Markdown-szintaxis beállításainak és más szerkesztői beállításoknak az felülírása.
és .
A statikus weboldalak szerkesztőjével a fájl bevezető részének szerkesztése.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A bevezető rész (front matter) egy rugalmas és kényelmes módszer a weboldal-közvetítőgenerátor által feldolgozott adatfájlokban a lapváltozók meghatározására. Általában a lap címének, sablonnak vagy a szerzőnek a megadására használják, de bármilyen típusú metainformáció átadására is alkalmas a generátor számára a HTML-re való renderelés során. Minden adatfájl legfelső részébe beillesztve a bevezető rész általában YAML vagy JSON formátumú, és következetes és pontos szintaxist igényel. Azok a felhasználók, akik nem ismerik a speciális szintaxis szabályait, véletlenül érvénytelen jelöléseket adhatnak meg, ami formázási problémákat vagy akár az összeállítás kudarcát okozhatja.
A statikus weboldalak szerkesztőjének WYSIWYG szerkesztési módja már eltávolítja a bevezető részt a szerkesztőből, hogy elkerülje ezeket a formázási hibákat. Ez azonban nem lehetővé teszi a benne tárolt értékek módosítását anélkül, hogy visszatérne a forráskód szerkesztéséhez. A GitLab 13.4-ben bármely mezőhöz hozzáférhet és szerkesztheti annak értékét egy ismerős, űrlap-alapú felületen. A gomb megnyomásával Beállítások (Beállítások) megnyílik egy panel, ahol az elején meghatározott kulcsokhoz tartozó űrlapmezők jelennek meg. A mezők az aktuális értékkel vannak kitöltve, és bármelyikük szerkesztéséhez elegendő egyszerűen beírni az űrlapba. Az ilyen típusú bevezető szerkesztés elkerüli a szintaxissal kapcsolatos nehézségeket, és teljes ellenőrzést biztosít a tartalom felett, miközben egyenletes formázást nyújt a végső eredménynek.
és .
A GitLab for Jira és DVCS Connector mostantól a Core-ban érhető el.
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLabban a Jira felhasználóknak: és lehetővé teszik a GitLabban végzett commitok és merge kérések közvetlen megjelenítését a Jira-ban. A Jira-hoz való beépített integrációnkkal könnyedén navigálhat a két alkalmazás között a munka során.
Ezek a funkciók korábban csak a Premium tervünkben voltak elérhetők, de most már minden felhasználó számára elérhetők!
és .
Többségi szavazás a Gitaly klaszter tranzakcióihoz (béta verzió)
(CORE, STARTER, PREMIUM, ULTIMATE)
A Gitaly klaszter lehetővé teszi a Git tárolók replikálását több "meleg" Gitaly csomóponton. Ez növeli a hibatűrést az egyedi hibapontok megszüntetésével. , amelyeket a GitLab 13.3-ban vezettek be, széleskörű terjesztést igényel a változásokra az összes Gitaly csomóponton a klaszterben, de csak azok a Gitaly csomópontok, amelyek a fő csomóponttal egyetértenek, tárolják a változásokat lemezen. Ha a replikációs csomópontok nem értenek egyet, csak egy példány a változásról kerül tárolásra lemezen, létrehozva ezzel egy egyedi hibapontot az aszinkron replikáció befejezéséig.
A többségi szavazás fokozza a hibatűrést, mivel a legtöbb csomópont (nem mind) egyetértését igényli a változások lemezen való tárolása előtt. Ha ez a váltható funkció be van kapcsolva, a rögzítést sikeresen kell végrehajtani több csomóponton. Az egyet nem értő csomópontok automatikusan szinkronizálódnak az aszinkron replikáció révén azokkal a csomópontokkal, amelyek megszerezték a kvorumot.
és .
Egyedi séma támogatása JSON validációhoz a Web IDE-ben
(PREMIUM, ULTIMATE, SILVER, GOLD)
Azok a projektek, ahol emberek JSON vagy YAML formátumban írják a konfigurációkat, gyakran problémákba ütköznek, mert könnyű elgépelni és elrontani valamit. Írhatunk ellenőrző eszközöket, amelyek ezeket a problémákat a CI csatornában ragadják meg, de a JSON séma fájl használata hasznos lehet a dokumentáció és a javaslatok biztosításához.
A projekt résztvevői megadhatják a tárolójukban az egyedi séma elérési útját a fájlban .gitlab/.gitlab-webide.yml, amely jelzi a sémát és a fájlok elérési útját a validációhoz. Amikor egy adott fájlt töltenek fel a Web IDE-be, látható lesz a további visszajelzés és ellenőrzés, amely segít a fájl elkészítésében.
és .
A direkt ciklikus grafikon (DAG) ágazási határa 50-re nőtt
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ha csatornákat használ (Directed Acyclic Graph (DAG)), észlelhette, hogy a feladatok által megadható limiti 10 volt a needs:, túl szigorú. A 13.4-es verzióban az alapértelmezett határértéket 10-ről 50-re emeltük, hogy bonyolultabb kapcsolati hálózatokat biztosítsunk a feladatok között a folyamataiban.
Ha Ön a GitLab felhasználói példányának adminisztrátora, akkor ezt a határértéket még magasabbra állíthatja egy kapcsolható funkció beállításával, bár ezt hivatalosan nem támogatjuk.
és .
Javított viselkedés needs kihagyott feladatokhoz
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Egyes esetekben a folyamatban lévő kihagyott feladat tévesen sikeresnek minősült a megadott függőségekhez, needs, ami miatt a következő feladatok elindultak, ami nem kellett volna megtörténjen. Ezt a viselkedést a 13.4-es verzióban kijavítottuk, és needs most már helyesen kezeli a kihagyott feladatok esetét.
és .
Rögzítse a feladat legutolsó artefaktumát, hogy megakadályozza annak törlését
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab mostantól automatikusan zárolja a sikeres feladat és folyamat legutolsó artefaktumát bármely aktív ágon, merge kéréseknél vagy címkén, hogy megakadályozza annak törlését a lejárati idő után. Könnyebbé válik agresszívebb lejárati szabályok beállítása a régi artefaktumok törlésére. Ez segít csökkenteni a lemezterület-fogyasztást, és biztosítja, hogy mindig legyen egy másolat a legutolsó artefaktumról a folyamatból.
és .
CI/CD útmutató a folyamat optimalizálásához
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A CI/CD folyamat optimalizálása növelheti a szállítás sebességét és pénzt takaríthat meg. Fejlesztettük a dokumentációnkat, hozzáadva egy rövid útmutatót, hogy maximális hasznot érhessen el a folyamatai optimalizálásából.
és .
A tesztelési jelentés a teszt státusza szerint van rendezve
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— ez egy egyszerű módja annak, hogy megtekinthessük az összes teszt eredményeit a folyamatban. Azonban nagy számú teszt esetén nehézkes lehet a sikertelen tesztek keresése, és sok időt vehet igénybe. További problémák, amelyek miatt nehézséget okozhat a jelentés használata, magukba foglalják a hosszú nyomkövetési kimenetek görgetésének nehézségeit és azt, hogy a 1 másodpercnél rövidebb idő alatt végrehajtott teszteknél az idő nullára kerekítésre kerül. Most a tesztelési jelentés alapértelmezés szerint először a sikertelen teszteket helyezi a jelentés elejére, majd a teszteket időtartam szerint rendezi. Ez leegyszerűsíti a hibák és a hosszú ideig tartó tesztek keresését. Ezenkívül a tesztek időtartama most milliszekundumban vagy másodpercben jelenik meg, így sokkal gyorsabban olvashatók, és a korábbi görgetési problémák is megoldódtak.
és .
A csomagok méretére vonatkozó korlátozások a csomagregisztrációban
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Most vannak korlátozások a csomagfájlok méretére, amelyeket feltölthetünk a GitLab csomagregisztrációba. Ezeket a korlátozásokat a csomagregisztráció teljesítményének optimalizálása és a visszaélések megelőzése érdekében vezették be. A korlátozások a csomag formátumától függően változnak. A GitLab.com esetében a maximális fájlméretek:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
A saját GitLab példányok esetében az alapértelmezett értékek ugyanolyanok. Az adminisztrátor azonban frissítheti a korlátozásokat a .
és .
Használja a CI_JOB_TOKEN-t a PyPI csomagok közzétételéhez
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab PyPI tárolóját használhatja Python csomagok létrehozására, közzétételére és megosztására, együtt a forráskódokkal és a CI/CD folyamatokkal. Korábban azonban nem tudott authentikálni a tárolóban a már meghatározott környezeti változóval, CI_JOB_TOKEN. Ennek következtében a saját hitelesítő adatait kellett használnia a PyPI tároló frissítéséhez, vagy talán úgy döntött, egyáltalán nem használja a tárolót.
Most már könnyebb a GitLab CI/CD használata a PyPI csomagok közzétételére és telepítésére a megadott környezeti változóval. CI_JOB_TOKEN.
és .
DAST szkenner profilok igény szerint
(ULTIMATE, GOLD)
Az igény szerinti DAST szkennelés, amelyet a , hozzáadódott a DAST szkenner profilok. Ezek bővítik a szkennelés konfigurálásának lehetőségeit, lehetővé téve több profil gyors létrehozását különböző szkennelési típusok lefedésére. A 13.4 verzióban a szkenner profilja alapértelmezésként tartalmaz egy robot időkorlát paramétert, amely beállítja, hogy a DAST robot mennyi ideig működjön, amikor megpróbálja felfedezni az összes oldalt a szkennelendő weboldalon. A profil tartalmaz egy céloldal időkorlát paramétert is, amely beállítja, hogy a szkenner mennyi ideig várjon, amíg a weboldal elérhetővé válik, mielőtt megszakítaná a szkennelést, ha az oldal nem válaszol 200 vagy 300 állapotkóddal. Ahogy ezt a funkciót ismételten fejlesztjük a következő kiadásokban, a szkenner profiljába további konfigurációs paraméterek fognak bekerülni.
és .
Egyszerű átirányítási konfigurációs fájl a GitLab Pages-hez
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ha a GitLab Pages-t használja, és jobban szeretné kezelni az URL változásokat, lehet, hogy észrevette, hogy az átirányításokat a GitLab Pages weboldalán lehetetlen kezelni. A GitLab most lehetővé teszi, hogy szabályokat állítson be egy URL átirányítására egy másikra a Pages weboldalához, egy konfigurációs fájl hozzáadásával a tárolóhoz. E funkció elérhetőségéhez Kevin Barnett (), Eric Eastwood () és a GitLab csapata is hozzájárult. Köszönjük mindenkinek a támogatást.
és .
A Terraform állapot, amelyet a GitLab kezel
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A Terraform állapot korábbi verzióihoz való hozzáférés szükséges a megfeleléshez és a hibakereséshez, amikor szükséges. A GitLab által kezelt Terraform állapot verziókezelése támogatva van a GitLab 13.4 verziójától kezdve. A verziókezelés automatikusan aktiválódik az új Terraform állományoknál. A meglévő Terraform állományok a későbbi kiadásokban.
és .
Fontos részletek az incidens értesítésekről
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Incidensek kezelésekor könnyen meghatározhatja, mennyi ideig volt nyitva a figyelmeztetés és hányszor történt esemény. Ezek a részletek gyakran döntő jelentőségűek az ügyfélre gyakorolt hatás meghatározásakor, valamint abban, hogy csapata mivel foglalkozik először. Az új incidensek részletező panelen megjelenítjük a figyelmeztetés kezdetének időpontját, az események számát és a forrásfigyelmeztetés hivatkozását. Ez az információ elérhető az értesítésekből létrejövő incidenseknél.
és .
Incidensek súlyossági szintjének beállítása és szerkesztése
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A "súlyosság" paraméter lehetővé teszi a reagáló szakemberek és érdekelt felek számára, hogy meghatározzák a szolgáltatáskimaradás következményeit, valamint a válaszadási módszereket és sürgősséget. Amint csapata megosztja az eredményeket az incidensek elhárítása során és helyreállítja a működést, módosíthatják ezt a paramétert. Most a jobb oldali panelen szerkesztheti az incidens súlyosságát, a súlyossági fokozat pedig megjelenik az incidensek listájában.
és .
Hálózati biztonsági szabályok létrehozása, szerkesztése és törlése konténerekhez
(ULTIMATE, GOLD)
Ez a konténerhálózati biztonsági szabályok szerkesztőjének fejlesztése lehetővé teszi a felhasználók számára, hogy könnyedén létrehozzák, szerkesszék és töröljék saját szabályaikat közvetlenül a GitLab felhasználói felületén. A szerkesztő funkciói közé tartozik a .yaml tapasztalt felhasználók számára tervezett mód és egy intuitív felület a hálózati szabályokkal kevésbé ismerős felhasználók számára. Az új szabálykezelési lehetőségeket a Biztonság és megfelelés > Fenyegetéskezelés > Szabályok (Security & Compliance > Threat Management > Policies).
és .
Azure blob-objektumtárolás támogatása
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
A GitLab és a GitLab Runner mostantól támogatja mely megkönnyíti a GitLab szolgáltatások futtatását Azure-ban.
A GitLab példányok támogatják az Azure-t minden típusú objektumtárolás esetében, beleértve az LFS fájlokat, a CI artefaktumokat és . Az Azure blob-objektumtárolás beállításához kövesse az vagy .
A GitLab feladatkezelők szintén támogatják az Azure-t a tároláshoz . Az Azure tárolás a következő szakaszban állítható be .
és .
Omnibus ARM64 csomagok Ubuntu és OpenSUSE számára
(CORE, STARTER, PREMIUM, ULTIMATE)
A 64 bites ARM architektúra GitLab indításának támogatása iránti növekvő keresletre válaszul örömmel bejelentjük az ARM64 Ubuntu 20.04 Omnibus hivatalos csomagjának elérhetőségét. Külön köszönet Zitai Chennek és Guillaume Gardetnek az óriási hozzájárulásukért – merge-kereseteik kulcsszerepet játszottak ebben!
Az Ubuntu 20.04 csomag letöltéséhez és telepítéséhez látogasson el a és válassza a Ubuntu.
és .
Okos kártyákkal való hitelesítés támogatása GitLab Helm chart esetén
(PREMIUM, ULTIMATE)
Okos kártyák, például a közös hozzáférésű kártyák (CAC), mostantól használhatók a Helm chart-on keresztül telepített GitLab instance hitelesítésére. Az okos kártyák az X.509 tanúsítványok segítségével hitelesítik magukat a helyi adatbázisban. Ennek köszönhetően a Helm chart-okkal való okos kártyás támogatás most már összhangban áll az Omnibus telepítésekben elérhető okos kártyás támogatással.
és .
A részletes kiadási jegyzetek és a frissítési/t együtttelepítési utasítások az eredeti angol nyelvű bejegyzésben olvashatóak: .
A fordításon angolról dolgoztak , , és .
Forrás: habr.com
