Byla vydána verze 13.4 s úložištěm HashiCorp pro CI proměnné, Kubernetes Agent a centrem zabezpečení, stejně jako přepínatelnými funkcemi ve Starteru.
V GitLabu neustále přemýšlíme o tom, jak pomoci uživatelům snížit rizika, zvýšit efektivitu a zrychlit dodávky na vaší oblíbené platformě. Tento měsíc jsme přidali mnoho užitečných novinek, které rozšiřují možnosti zabezpečení, snižují počet zranitelností, zvyšují efektivitu, usnadňují práci s GitLabem a pomáhají vašemu týmu dodávat funkce ještě rychleji. Doufáme, že pro vás budou užitečné klíčové funkce tohoto vydání, jakož i 53 dalších nových funkcí, které byly přidány v tomto vydání.
Rozšířené možnosti zabezpečení
Každý měsíc se snažíme přidávat několik nových funkcí do GitLab DevSecOps a toto vydání není výjimkou. v rámci sestavení a nasazení. Kromě toho organizace, které chtějí udržovat rozdělení povinností při nasazování kódu, nyní mohou . Tato role odpovídá a umožní potvrzovat sloučení žádostí a nasazovat kód v zabezpečených prostředích, aniž by bylo třeba poskytovat přístup ke změnám samotného kódu.
Dalším způsobem, jak snížit rizika, je použití nového . Provozní specialisté mohou nasazovat Kubernetes clustry z GitLab bez nutnosti otevírat přístup k jejich clustru pro celý internet. Také představujeme automatickou podporu pro verze nových souborů stavu Terraform s pro podporu souladu s požadavky a usnadnění ladění. A nakonec se panel zabezpečení v instanci změnil na s zprávami o zranitelnostech a nastavením zabezpečení.
Pohodlnější a efektivnější práce s GitLabem
Vylepšili jsme náš globální vyhledávač tím, že jsme do něj přidali , která umožňuje snadno přecházet na poslední tikety, skupiny, projekty, nastavení a sekce nápovědy. S radostí oznamujeme, že v GitLab Pages pro přesměrování jednotlivých stránek a adresářů na webu, což uživatelům umožní efektivněji rozvíjet své weby. A ti, kteří by chtěli získat podrobnější informace o nasazení, mají k dispozici tento release, který umožňuje !
Vklady s otevřeným zdrojovým kódem
Představujeme , které přidal . Záznamy o pokrytí unit testy změněného kódu poskytují vývojářům jasný přehled o pokrytí kódu při revizi; tyto informace pomáhají urychlit revizi a zmenšit čas potřebný na merge a nasazení nového kódu. A navíc jsme a plánujeme .
A to je teprve začátek!
Jako vždy, v obecné přehledu je příliš málo místa, a skvělých funkcí v release 13.4 je opravdu hodně. Zde je ještě několik:
- .
Pokud chcete předem vědět, co vás čeká v dalším release, podívejte se na .
.
tohoto měsíce —
Fabio přispěl významným v — funkcí, na kterou komunita GitLab dlouho čekala. Je to skutečně důležitý příspěvek s netriviálními změnami, které si vyžádaly neustálou spolupráci s členy týmu GitLab a týkaly se mnoha oblastí projektu, jako je UX, frontend a backend.
Hlavní funkce release GitLab 13.4
Používejte klíče HashiCorp Vault v CI úlohách
(PREMIUM, ULTIMATE, SILVER, GOLD)
V release 12.10 GitLab představil schopnost získávat a předávat klíče v CI úlohách pomocí handleru úloh GitLab (GitLab runner). Nyní rozšiřujeme , přidáním nové syntaxe secrets do souboru .gitlab-ci.yml. To usnadní nastavení a používání úložiště HashiCorp s GitLab.
a .
Představujeme GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Integrace GitLab s Kubernetes již delší dobu umožňuje nasazení na klastry Kubernetes bez nutnosti ruční konfigurace. Mnoha uživatelům se líbí jednoduchost použití této kombinace, zatímco jiní narazili na určité potíže. Pro aktuální integraci musí být váš klastr dostupný z internetu, aby mu GitLab mohl přistupovat. Pro mnoho organizací to není možné, protože omezují přístup ke klastrům z bezpečnostních důvodů, dodržování předpisů nebo regulačních důvodů. Aby se těmto omezením vyhnuli, museli uživatelé vytvářet své nástroje nad GitLabem, jinak by nemohli tuto funkci využívat.
Dnes představujeme GitLab Kubernetes Agent – nový způsob nasazení na klastry Kubernetes. Agent pracuje uvnitř vašeho klastru, takže ho nebudete muset otevírat pro celý internet. Agent koordinuje nasazení, a to dotazováním na nové změny u GitLab, místo aby GitLab posílal aktualizace na klastr. Bez ohledu na to, jakou metodu GitOps používáte, GitLab vám bude vyhovovat.
Všimněte si, že toto je první verze agenta. V současné době jsme se zaměřili na konfiguraci a správu nasazení prostřednictvím kódu pro GitLab Kubernetes Agent. Některé stávající funkce integrace Kubernetes, jako jsou desky nasazení a aplikace řízené GitLabem, v současnosti nejsou podporovány. , že tyto funkce budou přidány do agenta v budoucích verzích, stejně jako nové integrace zaměřené na bezpečnost a dodržování předpisů.
a .
Poskytujte uživatelům oprávnění k nasazení bez přístupu ke kódu
(PREMIUM, ULTIMATE, SILVER, GOLD)
Dříve systém oprávnění v GitLab neumožňoval správně oddělit povinnosti ve vaší týmu mezi těmi, kdo se věnují vývoji, a těmi, kdo se věnují nasazení. S vydáním GitLab 13.4 můžete udělit oprávnění k potvrzení merge requestů pro nasazení, stejně jako k vlastnímu nasazení kódu lidem, kteří nenapíšou kód, a to aniž byste jim poskytli přístupová práva maintainerů (v české lokalizaci GitLab „udržovatel“).
a .
Centrum zabezpečení
(ULTIMATE, GOLD)
Dříve bylo řízení zranitelností na úrovni instance omezeno jak funkcionalitou, tak flexibilitou. Rozhraní představovalo jednu stránku, která spojovala detaily zranitelností, grafy metrik a nastavení. Nebylo příliš mnoho prostoru pro rozvoj těchto funkcí nebo využívání jiných bezpečnostních nástrojů.
Učinili jsme zásadní změny v řízení bezpečnosti a její transparentnosti v GitLab. Panel zabezpečení instance se přeměnil na celý bezpečnostní centrum. Největší změnou je zavedení nové struktury nabídky: místo jedné stránky nyní vidíte zvlášť panel řízení bezpečnosti, zprávu o zranitelnostech a sekci nastavení. I když se funkcionalita nezměnila, rozdělení na části umožní zlepšovat tuto sekci, což by bylo jinak obtížné. To také vytváří základ pro přidání dalších funkcí týkajících se bezpečnosti v budoucnu.
Speciální sekce pro zprávu o zranitelnostech nyní má více prostoru pro zobrazení důležitých detailů. Zde jsou shromážděny zranitelnosti, které jsou aktuálně v seznamu zranitelností projektu. Přesun widgetů s metrikami zranitelností do samostatné sekce vytváří pohodlný panel řízení bezpečnosti. Nyní je to plátno pro budoucí vizualizace - nejen pro řízení zranitelností, ale i pro jakékoli metriky týkající se bezpečnosti. Nakonec samostatná oblast nastavení vytváří společný prostor pro všechna bezpečnostní nastavení na úrovni instance, nejen pro řízení zranitelností.
a .
Přepínatelné funkce nyní v GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
V GitLab 11.4 byla vydána . V 12.2 jsme zavedli strategie a , a v 13.1 jsme přidali a pro různé prostředí.
Na začátku tohoto roku se GitLab zavázal do otevřeného zdrojového kódu. V této verzi jsme dokončili přesun přepínatelných funkcí do plánu Starter a budeme pokračovat v jejich přesunu do Core s . Jsme rádi, že tuto možnost poskytujeme většímu počtu uživatelů a chceme vědět, jak je budete využívat.
a .
Rychlá navigace z vyhledávacího pole
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Někdy při navigaci v GitLabu chcete okamžitě přejít k určitému projektu, nikoli na stránku s výsledky vyhledávání.
S panelem globálního vyhledávání můžete rychle přejít k posledním tiketům, skupinám, projektům, nastavením a sekcím nápovědy. Můžete dokonce použít klávesovou zkratku /, abyste se přesunuli na vyhledávací panel, a tím efektivněji se pohybovali po GitLabu!
a .
Zobrazení pokrytí kódu v diffech merge requestů
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Při revizi merge requestu může být obtížné určit, zda je změněný kód pokryt unit testy. Místo toho mohou revizoři spoléhat na celkové pokrytí a požadovat jeho zvýšení před potvrzením merge requestu. To může vést k chaotickému přístupu k psaní testů, což ve skutečnosti nezlepší kvalitu kódu nebo jeho pokrytí testy.
Nyní při prohlížení diffu merge requestu uvidíte přehledné zobrazení pokrytí kódu. Nové označení rychle ukáže, zda je změněný kód pokryt unit testem, což pomůže urychlit revizi kódu a čas potřebný k sloučení a nasazení nového kódu.
Děkuji a Siemens za tuto funkci!
a .
Více prostředí a projektů na panelu prostředí
(PREMIUM, ULTIMATE, SILVER, GOLD)
Od verze GitLab 12.5 můžete pomocí sledovat stav prostředí, ale ne více než sedm prostředí ve třech projektech. Tento panel jsme zlepšili ve verzi 13.4, rozdělením na stránky, abychom vám pomohli spravovat a řídit vaše prostředí ve velkém měřítku. Nyní můžete vidět více prostředí ve více projektech.
a .
GitLab přijal správu poskytovatele GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nedávno jsme a plánujeme . V posledním měsíci jsme přijali 21 merge requestů a uzavřeli 31 tiketů, včetně některých dlouho existujících chyb a chybějících funkcí, jako je . Můžete naleznout v dokumentaci k Terraformu.
a .
Fuzzing testování API se specifikacemi OpenAPI nebo HAR souborem
(ULTIMATE, GOLD)
Fuzzing testování API je skvělý způsob, jak najít chyby a zranitelnosti ve vašich webových aplikacích a API, které mohou ostatní skenery a metody testování přehlédnout.
Testování API fuzzingem v GitLab umožňuje poskytnout nebo vaší aplikace a poté automaticky generuje náhodná vstupní data určená k ověření okrajových případů a hledání chyb. Výsledky se okamžitě zobrazují v rámci vašeho pipeline.
Toto je naše první vydání testování API fuzzingem a rádi se dozvíme, co si o tom myslíte. Pro fuzzing testování máme ještě , na kterých budeme stavět na základě tohoto vydání této funkce.
a .
Náhled nových grafů na panelu metrik
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dříve bylo vytvoření grafu na panelu metrik v GitLab obtížným úkolem. Poté, co jste vytvořili metriku v YAML souboru panelu, provedli jste změny v master, aniž byste měli možnost zkontrolovat, zda právě vytvořený graf funguje přesně tak, jak potřebujete. Od tohoto vydání si můžete předem prohlédnout změny při vytváření grafu a získat představu o výsledku před odesláním změn do YAML souboru panelu.
a .
Údaje o pokrytí kódu testy napříč všemi projekty skupiny
(PREMIUM, ULTIMATE, SILVER, GOLD)
Když spravujete velké množství projektů v GitLab, potřebujete jednotný zdroj informací o tom, jak se časem mění pokrytí kódu napříč všemi projekty. Dříve zobrazování těchto informací vyžadovalo únavnou a pracnou ruční práci: museli jste stáhnout údaje o pokrytí kódu testy z každého projektu a sloučit je do tabulky.
Ve vydání 13.4 se objevila možnost snadno a rychle shromáždit do .csv souboru všechna data o pokrytí kódu napříč všemi projekty skupiny nebo vybranými projekty. Tato funkce je MVC a bude následovat možnost .
a .
Podpora nových jazyků pro kompletní fuzzing testování
(ULTIMATE, GOLD)
Toto vydání představuje podporu několika nových jazyků pro fuzzing testování zaměřené na kompletní pokrytí.
Nyní můžete vyhodnotit všechny možnosti fuzzingového testování ve svých aplikacích na Javě, Rustu a Swiftu a najít chyby a zranitelnosti, které mohou ostatní skenery a testovací metody přehlédnout.
a .
Oznámení na hlavní stránce prostředí
(PREMIUM, ULTIMATE, SILVER, GOLD)
Stránka prostředí ukazuje celkový stav vašich prostředí. V této verzi jsme vylepšili tuto stránku přidáním zobrazení oznámení. Aktivovaná oznámení spolu se stavem vašich prostředí vám pomohou rychleji reagovat na vzniklé situace.
a .
Vnořené pipeline nyní mohou spouštět své vnořené pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Při použití vnořených pipeline je nyní možné spouštět nové pipeline uvnitř podřízených pipeline. Další úroveň hloubky může být užitečná, pokud potřebujete flexibilitu pro generování proměnného počtu pipeline.
Dříve, při použití vnořených pipeline, každá podřízená pipeline vyžadovala spouštěcí úkol, který byl manuálně zadán v nadřazené pipeline. Nyní můžete vytvářet vnořené pipeline, které budou dynamicky spouštět libovolný počet nových vnořených pipeline. Například, pokud máte monorepo, můžete dynamicky generovat první vnořenou pipeline, která sama vytvoří potřebný počet nových pipeline na základě změn ve větvi.
a .
Vylepšená navigace mezi nadřazenými a vnořenými pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pohyb mezi nadřazenými a vnořenými pipeline byl dříve dost nepohodlný — bylo třeba mnoha kliknutí, abyste se dostali k příslušné pipeline. Také bylo obtížné pochopit, který úkol spustil tuto pipeline. Nyní bude mnohem jednodušší vidět propojení mezi nadřazenými a vnořenými pipeline.
a .
Paralelní maticové úkoly zobrazují relevantní proměnné v názvu úkolu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pokud jste používali , mohli jste si všimnout, že bylo obtížné určit, která maticová proměnná byla použita pro konkrétní úkol, protože názvy úkolů vypadaly jako matrix 1/4Ve verzi 13.4 uvidíte relevantní hodnoty proměnných, které byly použity v tomto úkolu, místo obecného názvu úkolu. Například pokud je vaším cílem ladění pro architekturu x86, bude úkol nazván matice: ladění x86.
a .
Další vylepšení v GitLab 13.4
Připojení účtu Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Uživatelé GitLab nyní mohou připojit své účty GitLab k účtu Atlassian Cloud. To umožní přihlášení do GitLab pomocí přihlašovacích údajů Atlassian a také položí základy pro budoucí vylepšení integrace a s dalšími produkty z portfolia Atlassian.
a .
Export seznamu všech commitů sloučení
(ULTIMATE, GOLD)
Organizacím zaměřeným na splnění požadavků je potřeba způsob, jak auditorům ukázat ucelený pohled na komponenty související s jakoukoliv konkrétní změnou v produkci. To v rámci GitLab znamená shromáždit na jednom místě vše: žádosti o sloučení, tikety, kanály, skenování zabezpečení a další informace o commitech. Dosud jste museli buď ručně shromažďovat tyto informace v GitLab, nebo si nastavovat vlastní nástroje pro sběr informací, což nebylo příliš efektivní.
Nyní můžete programově sbírat a exportovat tyto údaje, abyste splnili požadavky auditu nebo provedli další analýzy. Chcete-li exportovat seznam všech commitů sloučení pro aktuální skupinu, musíte přejít na a kliknout na tlačítko Seznam všech commitů sloučení. Výsledný soubor bude obsahovat všechny commity žádosti o sloučení, jejich autora, ID související žádosti o sloučení, skupinu, projekt, potvrzení a další informace.
a .
Výstup seznamu a správa osobních přístupových tokenů prostřednictvím API
(ULTIMATE, GOLD)
Správa přístupu k prostoru jmen GitLab je zásadní součástí dodržování předpisů. Od principů minimálních oprávnění po časově omezený přístup – může být několik požadavků souvisejících s osobními tokeny přístupu v GitLab. Aby bylo snazší spravovat a řídit tyto uživatelské údaje v rámci vašeho prostoru jmen, poskytli jsme možnost exportovat seznam všech osobních tokenů přístupu a volitelně přes API.
Tyto vylepšení v API GitLab umožňují uživatelům exportovat seznam a zrušit své vlastní osobní tokeny přístupu, zatímco administrátoři mohou exportovat seznam a zrušit tokeny svých uživatelů. Nyní bude pro administrátory snazší vidět, kdo má přístup k jejich prostoru jmen, rozhodovat o poskytování přístupu na základě uživatelských údajů a také rušit osobní tokeny přístupu, které mohly být kompromitovány nebo které překračují pravidla společnosti pro správu přístupu.
a .
Související tikety a další funkce nyní v GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Před několika měsíci jsme oznámili plán na . Při dodržování tohoto slibu jsme vytvořili , a (v ruské lokalizaci GitLab „diskusní tabule“) dostupné v plánu Core. To se vztahuje pouze na vztahy typu „související s“, vztahy typu „blokuje“ a „je blokován“ zůstávají v placených plánech.
a .
Zobrazení názvu zdrojové větve na bočním panelu merge requestu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Při revizi změn v kódu, diskusí a commitů merge requestu je často žádoucí provést místní checkout větve pro hlubší revizi. Nicméně najít název větve se stává stále obtížnější, jakmile se do popisu merge requestu přidává více obsahu, a je nutné procházet dál dolů stránkou.
Přidali jsme název větve na boční panel merge requestu, což jej činí dostupným kdykoliv a eliminuje potřebu procházet celou stránku. Stejně jako odkaz na merge request obsahuje sekce se zdrojovou větví užitečné tlačítko „zkopírovat“.
Děkuji za obrovský přínos k vývoji této funkce!
a .
Upozornění na existenci sbalených souborů v diffech merge requestu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Merge requesty, které přidávají změny do několika souborů, občas sbalují diffy velkých souborů, aby zlepšily výkon zobrazení. Když k tomu dojde, může být při revizi náhodně přehlédnut soubor, zejména u merge requestů s velkým počtem souborů. Od verze 13.4 budou merge requesty označovat diffy obsahující sbalené soubory, díky čemuž nezmeškáte tyto soubory během revize kódu. Pro ještě větší jasnost plánujeme do budoucího uvolnění přidat zvýraznění těchto souborů. Sledujte aktualizace v .
a .
Upozornění na existenci sbalených souborů v diffe merge requestu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
V sekci s diffy merge requestů jsou velké soubory sbaleny pro zvýšení výkonu. Při revizi kódu však mohou být některé soubory přehlédnuty, když revizor prochází seznam souborů, protože všechny velké soubory jsou sbaleny.
Přidali jsme viditelné upozornění nahoře na stránce diffu merge requestu, aby informovalo uživatele, že v této sekci jsou sbalené soubory. Takto nezmeškáte žádné změny v merge requestu při revizi.
a .
Automatické obnovení repozitáře Gitaly clusteru
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dříve, když se primární uzel clusteru Gitaly odpojil, byly repozitáře na tomto uzlu označeny jako pouze pro čtení. To bránilo ztrátě dat v situacích, kdy byly na uzlu provedeny změny, které ještě nebyly replikovány. Po opětovném připojení uzlu se GitLab automaticky neobnovoval a administrátoři museli ručně spuštění proces synchronizace nebo se smířit se ztrátou dat. Mohly také dojít k situacím, kdy se objevily zastaralé nebo pouze pro čtení repozitáře z jiných důvodů, jako je neúspěšné dokončení úkolu replikace na sekundárním uzlu. V tomto případě zůstal repozitář zastaralý, dokud nebyla provedena další operace zápisu, která by spustila úkol replikace.
Pro vyřešení tohoto problému Nyní je naplánován úkol replikace, když zjistí zastaralé úložiště na jednom uzlu a poslední verzi úložiště na jiném. Tento úkol replikace automaticky aktualizuje úložiště, což eliminuje potřebu ručního obnovení dat. Automatické obnovení také zajišťuje rychlé uvedení sekundárních uzlů do aktuálního stavu, pokud úkol replikace selže, místo abyste museli čekat na další zapisovací operaci. Vzhledem k tomu, že mnoho Gitaly clusterů ukládá velké množství úložišť, výrazně to snižuje čas, který administrátoři a inženýři zajištění spolehlivosti stráví obnovováním dat po chybě.
Kromě toho automatické opravy spouští replikaci úložišť na jakémkoli novém uzlu Gitaly přidaném do clusteru, což eliminuje ruční práci při přidávání nových uzlů.
a .
Označte úkol to-do jako dokončený na stránce návrhu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Efektivní komunikace v GitLabu je založena na seznamech úkolů to-do. Pokud jste byli zmíněni v komentáři, je kriticky důležité mít možnost přejít k úkolu a buď začít něco dělat, nebo jej označit jako již splněný. Také je důležité mít možnost přidělit si úkol, když potřebujete na něčem zapracovat nebo se k tomu vrátit později.
Dříve jste nemohli přidávat úkoly nebo je označovat jako splněné při práci s návrhy. To vážně narušilo efektivitu komunikace mezi produktovými týmy, protože úkoly to-do jsou kriticky důležitým prvkem pracovního procesu v GitLabu.
Ve verzi 13.4 dohánějí návrhy komentáře k tiketům v používání úkolů, což usnadňuje jejich práci a činí ji efektivnější.
a .
Vylepšená příručka pro odstraňování problémů pro CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vylepšili jsme příručku pro odstraňování problémů pro GitLab CI/CD přidáním dalších informací o běžných problémech, se kterými se můžete setkat. Doufáme, že vylepšená dokumentace bude cenným zdrojem, který vám pomůže rychle a snadno nastavit a spustit GitLab CI/CD.
a .
Merge requesty už nevypadávají z fronty pro sloučení
(PREMIUM, ULTIMATE, SILVER, GOLD)
Dříve mohly merge requesty náhodně vypadnout z fronty pro sloučení kvůli pozdním komentářům. Pokud byl merge request již ve frontě a někdo k němu přidal komentář, který vytvořil nové nevyřešené diskuse, byl merge request považován za nevhodný pro sloučení a vypadl z fronty. Nyní, poté co je merge request přidán do fronty pro sloučení, lze přidávat nové komentáře, aniž byste se obávali, že narušíte proces sloučení.
a .
Zobrazení hodnoty pokrytí kódu v merge requestu pro úkol
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vývojáři by měli mít možnost vidět hodnotu pokrytí kódu po dokončení kontejneru — i v složitých scénářích, jako je práce kontejneru s více úkoly, které je třeba parsovat, aby se spočítala hodnota pokrytí. Dříve widget merge requestu zobrazoval pouze průměr těchto hodnot, což znamenalo, že jste museli přecházet na stránku úkolu a zpět k merge requestu, abyste získali mezilehlé hodnoty pokrytí. Abychom vám ušetřili čas a zbavili vás těchto zbytečných kroků, přidali jsme do widgetu zobrazení průměrné hodnoty pokrytí, její změny mezi cílovými a výchozími větvemi a kontextovou nápovědu, která zobrazuje hodnotu pokrytí pro každý úkol, na jehož základě byla vlastněna průměrná hodnota.
a .
Odstranění balíčků z registru balíčků při prohlížení skupiny
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Registr balíčků GitLab je místo pro ukládání a distribuci balíčků v různých formátech. Když má váš projekt nebo skupina mnoho balíčků, potřebujete rychle identifikovat nepoužívané balíčky a odstraňovat je, aby je lidé nemohli stahovat. Můžete odstraňovat balíčky ze svého registru přes nebo přes uživatelské rozhraní registru balíčků. Nicméně zatím jste nemohli odstraňovat balíčky při prohlížení skupiny přes uživatelské rozhraní. Výsledkem bylo, že jste museli odstraňovat zbytečné balíčky samostatně pro každý projekt, což bylo neefektivní.
Nyní můžete odstraňovat balíčky při prohlížení registru balíčků skupiny. Stačí přejít na stránku registru balíčků skupiny, filtrovat balíčky podle jména a odstranit všechny nepotřebné.
a .
Škálování balíčků Conan na úroveň projektu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Můžete používat repozitář Conan v GitLab pro publikaci a distribuci závislostí C/C++. Dříve bylo možné škálovat balíčky pouze na úroveň instance, protože název balíčku Conan mohl mít maximálně 51 znaků. Pokud jste chtěli publikovat balíček z podskupiny, například gitlab-org/ci-cd/package-stage/feature-testing/conan, bylo to téměř nemožné provést.
Nyní můžete škálovat balíčky Conan na úroveň projektu, což usnadňuje publikaci a distribuci závislostí vašich projektů.
a .
Podpora nových manažerů balíčků a jazyků pro skenování závislostí
(ULTIMATE, GOLD)
S radostí oznamujeme, že jsme přidali skenování závislostí pro projekty napsané v C, C++, C# a .Net, které používají NuGet 4.9+ nebo manažery balíčků Conan, do našeho seznamu . Nyní můžete zahrnout skenování závislostí jako součást fáze Secure, abyste kontrolovali známé zranitelnosti závislostí přidaných prostřednictvím manažerů balíčků. Nalezené zranitelnosti budou zobrazeny ve vaší žádosti o sloučení spolu s úrovní jejich závažnosti, abyste věděli před sloučením, jaká rizika nová závislost přináší. Můžete také nakonfigurovat svůj projekt tak, aby vyžadoval pro závislosti s kritickým (Critical), vysokým (High) nebo neznámým (Unknown) úrovněm nebezpečí.
a .
Oznámení při změně nastavení žádosti o sloučení na 'Sloučit při úspěšném dokončení pipeline'
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Dříve, když byla nastavena žádost o sloučení Sloučit, když pipeline dokončí (Merge When Pipeline Succeeds, MWPS), nebylo odesláno žádné emailové oznámení. Museli jste ručně kontrolovat stav nebo čekat na oznámení o dokončení sloučení. V této verzi s radostí představujeme příspěvek uživatele , který vyřešil tento problém přidáním automatického odesílání oznámení všem, kdo jsou přihlášeni k žádosti o sloučení, když revizor změní nastavení sloučení na MWPS.
a .
Vytváření klastrů EKS s verzí Kubernetes zadanou uživatelem
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Uživatelé GitLab nyní mohou sami vybrat verzi Kubernetes, která bude poskytnuta EKS; můžete vybírat mezi verzemi 1.14–1.17.
a .
Vytváření incidentů jako typů tiketů
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ne každá vznikající problém okamžitě spouští odeslání upozornění: uživatelé hlásí výpadky funkčnosti, zatímco členové týmů analyzují problémy s výkonem. Nyní jsou incidenty novým typem tiketu, takže vaše týmy je mohou rychle vytvářet v rámci obvyklého pracovního postupu. Klikněte Nový úkol kdekoli v GitLab a v poli Typ vyberte Incident.
a .
Zmiňování upozornění GitLab v Markdownu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Vylepšili jsme upozornění GitLab přidáním nového typu zmiňování speciálně pro ně v GitLab verzi Markdown, což usnadňuje sdílení upozornění a jejich zmínění. Použijte ^alert#1234, abyste zmínili upozornění v jakémkoli poli s Markdownem: v incidentech, tiketech nebo merge-requests. To vám také pomůže identifikovat úkoly, které jsou vytvářeny z upozornění, na rozdíl od tiketů nebo merge-requests.
a .
Zobrazení zátěže upozornění na incidentech
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Popis upozornění obsahuje informace, které jsou kritické pro diagnostiku výpadků a obnovu, a tyto informace by měly být snadno dostupné, abyste nemuseli přepínat nástroje nebo záložky při práci na řešení incidentu. Incidenty, které vznikly z upozornění, zobrazují úplný popis upozornění na kartě Podrobnosti o upozornění.
75% rychlejší rozšířené vyhledávání
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab jako jednotná aplikace má jedinečnou schopnost urychlit vyhledávání obsahu v celém pracovním procesu DevOps. V GitLab 13.4 rozšířené vyhledávání poskytuje výsledky o 75% rychleji, když je , jako na GitLab.com.
a .
Zobrazení odstraněných projektů pro administrátory
(CORE, STARTER, PREMIUM, ULTIMATE)
Možnost odložit odstranění projektu byla . Nicméně dříve nebylo možné vidět na jednom místě všechny projekty čekající na odstranění. Nyní mohou správci uživatelských instancí GitLab prohlížet všechny projekty čekající na odstranění na jednom místě — společně s tlačítky pro snadné obnovení těchto projektů.
Tato funkce umožňuje správcům lépe kontrolovat odstraňování projektů, shromažďující všechny potřebné informace na jednom místě a poskytující možnost zrušit nežádoucí akce odstraňování.
Děkuji díky za tuto funkci!
a .
Podpora pravidel push pro skupiny byla přidána do API
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
Dříve bylo možné nastavit skupinová pravidla push pouze při návštěvě každé skupiny individuálně prostřednictvím uživatelského rozhraní GitLab a aplikováním těchto pravidel. Nyní můžete spravovat tato pravidla prostřednictvím API pro podporu vašich uživatelských nástrojů a automatizaci GitLab.
a .
Odzvání osobních tokenů pro přístup k self-hosted úložišti přihlašovacích údajů
(ULTIMATE)
poskytuje správcům informace potřebné k správě přihlašovacích údajů uživatelů jejich instance GitLab. Jelikož se organizace orientující se na dodržování předpisů liší svou přísností v pravidlech správy přihlašovacích údajů, přidali jsme tlačítko, které umožňuje správcům na přání odvolat token osobního přístupu uživatele (PAT). Nyní mohou správci snadno odvolat potenciálně ohrožené PAT. Tato funkce je užitečná pro organizace, které potřebují flexibilnější možnosti pro zajištění dodržování předpisů s cílem minimalizovat rušení svých uživatelů.
a .
Konfigurační soubor pro editor statických stránek
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ve verzi GitLab 13.4 představujeme nový způsob nastavení editoru statických stránek. Přestože konfigurační soubor v této verzi neukládá ani neobtahuje žádné parametry, klademe základy pro budoucí nastavení chování editoru. V následujících verzích přidáme do souboru .gitlab/static-site-editor.yml parametry pro nastavení , na kterém , předefinování nastavení syntaxe Markdown a dalších nastavení editoru.
a .
Úprava úvodní části souboru pomocí editoru statických stránek
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Úvodní část (front matter) je flexibilní a pohodlný způsob, jak definovat proměnné stránky v datech určených k zpracování generátorem statických stránek. Obvykle se používá k nastavení názvu stránky, šablony nebo autora, ale může sloužit k předávání jakýchkoli metadat generátoru při rendrování stránky do HTML. Umístěná na samém vrcholu každého souboru dat, úvodní část je obvykle formátována jako YAML nebo JSON a vyžaduje konzistentní a přesnou syntaxi. Uživatelé, kteří nejsou obeznámeni s konkrétními syntaktickými pravidly, mohou neúmyslně zavést neplatnou značku, což může vést k problémům s formátováním nebo dokonce k selhání sestavení.
Režim WYSIWYG editoru statických stránek již skrývá úvodní část z editoru, aby se předešlo těmto chybným formátováním. Nicméně to neumožňuje změnit hodnoty uložené v této části bez návratu k editaci v kódu. V GitLab 13.4 můžete přistupovat k jakémukoli poli a měnit jeho hodnotu v obvyklém rozhraní na základě formulářů. Po kliknutí na tlačítko Nastavení (Nastavení) se otevře panel, na kterém je zobrazen formulář pro každou klíč definovanou na začátku. Pole jsou vyplněna aktuální hodnotou a pro úpravu jakéhokoliv z nich stačí jednoduše zadat jeho hodnotu do webového formuláře. Taková úprava úvodní části umožňuje vyhnout se složitostem syntaktického formátování a poskytuje vám plnou kontrolu nad obsahem, přičemž zajišťuje jednotné formátování konečného výsledku.
a .
GitLab pro Jira a DVCS konektor nyní v Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pro uživatele Jira v GitLab: a umožňují zobrazovat informace o commitech a merge requestech GitLab přímo v Jira. V kombinaci s naší integrovanou integrací s Jira můžete snadno přecházet mezi oběma aplikacemi během práce.
Tyto funkce byly dříve dostupné pouze v našem plánu Premium, nyní jsou dostupné všem uživatelům!
a .
Hlasování s většinou hlasů pro transakce clusteru Gitaly (beta verze)
(CORE, STARTER, PREMIUM, ULTIMATE)
Cluster Gitaly umožňuje replikaci Git repozitářů na několik 'teplých' uzlů Gitaly. To zvyšuje odolnost proti výpadkům tím, že eliminuje jednotlivé body selhání. , představené v GitLabu 13.3, vyžadují širokopásmový přenos změn na všechny uzly Gitaly v clusterech, ale pouze uzly Gitaly, které hlasují v souladu s primárním uzlem, uchovávají změny na disku. Pokud se všechny replikované uzly nedohodnou, pouze jedna kopie změny bude uložena na disku, čímž vznikne jediný bod selhání, dokud nedojde k asynchronní replikaci.
Hlasování s většinou hlasů zvyšuje odolnost proti výpadkům, protože vyžaduje souhlas většiny uzlů (a ne všech) před uložením změn na disku. Pokud je tato přepínací funkce zapnuta, záznam by měl být úspěšně proveden na několika uzlech. Nesouhlasené uzly se automaticky synchronizují pomocí asynchronní replikace z těch uzlů, které vytvořily kvorum.
a .
Podpora uživatelské schéma pro validaci JSON ve Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Projekty, kde lidé píší konfigurace ve formátu JSON nebo YAML, jsou často náchylné k problémům, protože je snadné udělat překlep a něco rozbít. Lze napsat validační nástroje, které tyto problémy zachytí v CI pipeline, ale použití souboru schématu JSON může být užitečné pro poskytování dokumentace a nápovědy.
Účastníci projektu mohou v jejich repozitáři definovat cestu k uživatelskému schématu v souboru .gitlab/.gitlab-webide.yml, který specifikuje schéma a cestu k souborům pro validaci. Při nahrávání určitého souboru do Web IDE bude viditelná dodatečná zpětná vazba a validace, která pomůže při vytváření souboru.
a .
Limit větvení orientovaného acyklického grafu (DAG) byl zvýšen na 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pokud používáte pipeline (Directed Acyclic Graph (DAG)), mohli jste zjistit, že omezení na 10 úloh, které může úloha specifikovat v needs:, příliš přísně. V 13.4 byl výchozí limit zvýšen z 10 na 50, aby se zajistily složitější sítě závislostí mezi úkoly ve vašich pipelinech.
Pokud jste administrátor uživatelského instance GitLab, můžete tento limit zvýšit ještě více nastavením přepínatelné funkce, ačkoli nenabízíme oficiální podporu pro tuto možnost.
a .
Vylepšené chování needs pro vynechané úkoly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
V některých případech mohl být vynechaný úkol v pipeline omylem považován za úspěšný pro závislosti uvedené v needs, kvůli čemuž byly spuštěny následující úkoly, což by se nemělo dít. Toto chování bylo opraveno ve verzi 13.4 a needs nyní správně zpracovává případy vynechaných úkolů.
a .
Zamkněte poslední artefakt úkolu, abyste zabránili jeho odstranění
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab nyní automaticky zamyká poslední artefakt úspěšného úkolu a pipeline na jakékoliv aktivní větvi, merge requestu nebo značce, aby se zabránilo jeho odstranění po uplynutí platnosti. Je snadnější nastavit agresivnější pravidla platnosti pro odstranění starých artefaktů. To pomáhá snížit spotřebu diskového prostoru a zajišťuje, že vždy máte kopii posledního artefaktu z pipeline.
a .
Příručka pro CI/CD k optimalizaci pipeline
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Optimalizace CI/CD pipeline může zvýšit rychlost dodání a ušetřit peníze. Vylepšili jsme naši dokumentaci přidáním stručného průvodce, jak získat maximální výnos z optimalizace vašich pipeline.
a .
Zpráva o testování je seřazena dle stavu testu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— je to jednoduchý způsob, jak vidět výsledky všech testů v pipeline. Nicméně při velkém počtu testů může hledání neúspěšných testů trvat dlouho. Dalšími problémy, které mohou ztížit používání zprávy, jsou obtíže při rolování dlouhých výstupních dat trasování a zaokrouhlení času na nulu pro testy prováděné za méně než 1 sekundu. Nyní report o testování při řazení nejprve umisťuje neúspěšné testy na začátek zprávy a poté řadí testy podle trvání. To zjednodušuje hledání selhání a dlouhých testů. Dále je trvání testů nyní zobrazováno v milisekundách nebo sekundách, takže je čtení mnohem rychlejší, a také byly vyřešeny předchozí problémy s rolováním.
a .
Omezení velikosti souborů nahrávaných do registru balíčků
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Nyní existují omezení velikosti souborů balíčků, které lze nahrávat do registru balíčků GitLab. Omezení byla přidána pro optimalizaci výkonu registru balíčků a prevenci zneužití. Omezení závisí na formátu balíčku. Pro GitLab.com jsou maximální velikosti souborů:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
Pro uživatelské instance GitLab jsou výchozí hodnoty stejné. Administrátor však může aktualizovat omezení pomocí .
a .
Použijte CI_JOB_TOKEN pro publikaci balíčků PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Můžete použít GitLab PyPI registry pro vytváření, publikaci a sdílení Python balíčků spolu se zdrojovým kódem a CI/CD pipeline. Nicméně dříve jste se nemohli autentizovat v registru pomocí předem definované proměnné prostředí CI_JOB_TOKEN. To vedlo k tomu, že jste museli používat své osobní údaje pro aktualizaci registru PyPI, nebo jste se možná rozhodli registr vůbec nepoužívat.
Nyní je snazší používat GitLab CI/CD pro publikaci a instalaci balíčků PyPI pomocí předem definované proměnné prostředí CI_JOB_TOKEN.
a .
Profily DAST z hlediska požadavku
(ULTIMATE, GOLD)
K DAST skenování na požadavek, které bylo , přibyly profily skeneru DAST. Ty rozšiřují možnosti konfigurace tohoto skenování, což umožňuje rychle vytvářet několik profilů pro pokrytí různých typů skenování. Ve verzi 13.4 profil skeneru původně zahrnuje parametr timeoutu pro prohledávač, který určuje, jak dlouho by měl prohledávač DAST běžet při pokusu o zjištění všech stránek skenovaného webu. Profil také zahrnuje parametr timeoutu pro cílový web, aby určoval, jak dlouho by měl skener čekat na to, až se web stane dostupným, než přeruší skenování, pokud web neodpovídá kódem stavu 200 nebo 300. Jak budeme tuto funkci stále více vylepšovat v budoucích verzích, budou do profilu skeneru přidány další konfigurační parametry.
a .
Jednoduchý konfigurační soubor přesměrování pro GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Pokud používáte GitLab Pages a chcete lépe spravovat změny URL, možná jste si všimli, že správa přesměrování na vašem webu GitLab Pages byla nemožná. GitLab nyní umožňuje nakonfigurovat pravidla pro přesměrování jedné URL na druhou pro váš web Pages přidáním konfiguračního souboru do repozitáře. Tato funkce se stala možnou díky účasti Kevina Barnetta (), našeho Erica Eastwooda () a týmu GitLab. Děkujeme všem za váš příspěvek.
a .
Stav Terraform řízený GitLabem
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Přístup k předchozím verzím stavu Terraform je nezbytný jak pro splnění požadavků, tak pro ladění v případě potřeby. Podpora správy verzí stavu Terraform řízeného GitLabem je nabízena od GitLab 13.4. Správa verzí se automaticky zapíná pro nové soubory stavu Terraform. Existující soubory stavu Terraform budou v pozdější verzi.
a .
Důležité detaily notifikací o incidentech
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Při zpracování incidentů musíte snadno určit, jak dlouho bylo upozornění otevřeno a kolikrát došlo k události. Tyto detaily často hrají klíčovou roli při určení dopadu na zákazníka a na to, co by vaše tým měl řešit jako první. Na nové panelu podrobností incidentu zobrazuje čas zahájení upozornění, počet událostí a odkaz na původní upozornění. Tyto informace jsou dostupné pro incidenty, které jsou vytvářeny z upozornění.
a .
Nastavení a úprava parametru závažnosti incidentu
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Parametr „závažnost incidentu“ umožňuje specialistům na reakci a zainteresovaným stranám určit důsledky poruchy, stejně jako metody a naléhavost reakce. Jak váš tým sdílí výsledky během odstranění incidentu a obnovuje provozuschopnost, mohou tento parametr měnit. Nyní můžete upravit závažnost incidentu na pravém postranním panelu stránky „Podrobnosti o incidentu“, zatímco úroveň závažnosti se zobrazuje v seznamu incidentů.
a .
Vytváření, úprava a odstraňování pravidel zabezpečení sítě kontejnerů
(ULTIMATE, GOLD)
Toto vylepšení editoru pravidel zabezpečení sítě kontejnerů umožňuje uživatelům snadno vytvářet, upravovat a odstraňovat svá pravidla přímo z uživatelského rozhraní GitLab. Schopnosti editoru zahrnují režim .yaml pro zkušené uživatele a editor pravidel s intuitivním rozhraním pro ty, kdo nejsou s síťovými pravidly obeznámeni. Nové možnosti správy pravidel najdete v části Bezpečnost a dodržování > Řízení hrozeb > Pravidla (Zabezpečení & Dodržování > Řízení hrozeb > Politiky).
a .
Podpora úložiště blob-objektů Azure
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Jak GitLab, tak GitLab Runner nyní podporují , což usnadňuje spouštění služeb GitLab v Azure.
Instance GitLab podporují Azure pro všechny typy úložišť objektů, včetně souborů LFS, artefaktů CI a . Pro nastavení úložiště blob-objektů Azure postupujte podle pokynů pro instalaci nebo .
Zpracovatelé úloh GitLab také podporují Azure pro ukládání . Azure Storage lze nastavit v sekci .
a .
Pakety Omnibus ARM64 pro Ubuntu a OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
V reakci na rostoucí poptávku po podpoře spuštění GitLab na 64bitové architektuře ARM s radostí oznamujeme dostupnost oficiálního balíčku ARM64 Ubuntu 20.04 Omnibus. Velké poděkování Zitai Chen a Guillaume Gardet za jejich významný přínos — jejich merge requesty hrály klíčovou roli!
Chcete-li stáhnout a nainstalovat balíček pro Ubuntu 20.04, přejděte na naši a vyberte si Ubuntu.
a .
Podpora autentizace pomocí smart karet pro GitLab Helm chart
(PREMIUM, ULTIMATE)
Smart karty, například Common Access Cards (CAC), lze nyní použít k autentizaci ve实例GitLab nasazeném prostřednictvím Helm chart. Smart karty se autentizují v místní databázi pomocí certifikátů X.509. Díky tomu je podpora smart karet s Helm chart nyní v souladu s podporou smart karet, která je dostupná v nasazeních Omnibus.
a .
Podrobné release notes a pokyny k aktualizaci/nastavení lze přečíst v originálním anglickém příspěvku: .
Na překladu z angličtiny pracovali , , a .
Zdroj: habr.com
