# GitLab 13.4 пуснат с хранилище на HashiCorp за CI променливи и Kubernetes Agent

Пуснато е издание 13.4 с хранилище на HashiCorp за CI променливи, Kubernetes Agent и център за сигурност и превключваеми функции в Starter

В GitLab винаги мислим за това как можете да помогнете на потребителите да намалят риска, да подобрят ефективността и да доставят по-бързо на любимата ви платформа. Този месец добавихме много страхотни нови функции, които подобряват сигурността, намаляват уязвимостите, подобряват ефективността, правят GitLab по-лесен за използване и помагат на вашия екип да предоставя функции още по-бързо. Надяваме се, че основните функции на изданието ще ви бъдат полезни 53 други нови функциидобавен в това издание.

Разширени функции за сигурност

Опитваме се да добавяме няколко нови функции към GitLab DevSecOps всеки месец и тази версия не е изключение. Тайните ключове от трезора на HashiCorp вече могат да се използват в CI/CD задачи по време на монтажа и внедряването. Освен това организациите, които желаят да поддържат разделяне на задълженията за внедряване на код, вече могат добавете потребители с достъп на Reporter до ролята на Deployer. Тази роля съответства принцип на най-малки привилегии за достъп и ще ви позволи да потвърждавате заявки за сливане (в руската локализация на GitLab, „заявки за сливане“) и да внедрявате код в защитени среди, без да предоставяте достъп за промяна на самия код.

Друг начин за намаляване на риска е използването на нови GitLab Kubernetes агент. Специалистите по операциите могат да разположат клъстери на Kubernetes от GitLab, без да се налага да излагат своя клъстер на целия интернет. Ние също така въвеждаме поддръжка за автоматичен контрол на версиите за нови файлове със състояние на Terraform Състояние на Terraform, управлявано от GitLab за поддържане на съответствие и лесно отстраняване на грешки. И накрая, контролният панел за сигурност на екземпляра се превърна в Център за сигурност GitLab с отчети за уязвимости и настройки за сигурност.

По-удобна и ефективна работа с GitLab

Подобрихме нашето глобално търсене, като добавихме бърза навигация от лентата за търсене, което ви позволява лесно да навигирате до най-новите билети, групи, проекти, настройки и теми за помощ. Щастливи сме да съобщим това в страниците на GitLab се появиха пренасочвания за пренасочване на отделни страници и директории в даден сайт, което позволява на потребителите да разгръщат сайтовете си по-ефективно. А за тези, които биха искали да получат разширена информация за внедряването, тази версия позволява управлявайте стотици поддържани внедрявания на проекти от лентата с инструменти на средата!

Приноси с отворен код

Ние представляваме показване на покритието на кода в diffs на искане за сливане, което добави MVP този месец, Фабио Хусер. Маркировките за покритие на теста на единица за промени в кода дават на разработчиците визуално представяне на покритието на кода по време на прегледи; тази информация помага за ускоряване на прегледите и намаляване на времето за обединяване и внедряване на нов код. А също и ние преместени флагове на функции в Starter и планирайте преместете ги в Core във версия 13.5.

И това е само началото!

Както винаги, има твърде малко място в общия преглед и има много страхотни функции във версия 13.4. Ето още няколко:

• Прегледайте списък с лични токени за достъп и ги отменете чрез API
• Отменете лични токени за достъп за самостоятелно управлявано хранилище на идентификационни данни
• Маркирайте завършени задачи на страницата за дизайн
• Вложените тръбопроводи (в руската локализация на GitLab "монтажни линии") вече могат да изпълняват свои собствени вложени тръбопроводи
• Поддръжка за удостоверяване на смарт карта за Helm chart GitLab.

Ако искате да знаете предварително какво ви очаква в следващия освобождаване, вижте нашият видеоклип за изданието 13.5.

Гледайте нашето уеб предаване „Устойчивост в предизвикателни времена“.

MVP този месец - Фабио Хусер

Фабио допринесе значително принос в показване на покритието на кода в diffs на искане за сливане - функция, която чакаше много дълго време в общността на GitLab. Това е наистина важен принос с нетривиални промени, които изискваха постоянно сътрудничество с членовете на екипа на GitLab и засегнаха много области на проекта, като UX, преден и бек-енд.

Основни характеристики на изданието GitLab 13.4

Използвайте HashiCorp Vault Keys в CI Jobs

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

Във версия 12.10 GitLab въведе възможността за получаване и предаване на ключове към CI задания с помощта на манипулатора на задания GitLab (GitLab runner). Сега се разширяваме удостоверяване с JWT, добавяйки нов синтаксис secrets да подаде .gitlab-ci.yml. Това ще улесни настройката и използването на хранилището на HashiCorp с GitLab.

Ключова документация и оригинален билет.

Представяме ви GitLab Kubernetes Agent

(PREMIUM, ULTIMATE) Етап на цикъла на DevOps: Конфигуриране

Интеграцията на GitLab с Kubernetes отдавна позволява внедряване на Kubernetes клъстери без необходимост от ръчна конфигурация. Много потребители харесаха лекотата на използване на този пакет, докато други срещнаха някои трудности. За текуща интеграция вашият клъстер трябва да е достъпен от интернет, така че GitLab да има достъп до него. За много организации това не е осъществимо, защото те ограничават достъпа до клъстери от съображения за сигурност, съответствие или регулаторни причини. За да заобиколят тези ограничения, потребителите трябваше да изградят своите инструменти върху GitLab, в противен случай нямаше да могат да използват тази функция.

Днес представяме GitLab Kubernetes Agent, нов начин за внедряване в клъстери на Kubernetes. Агентът работи във вашия клъстер, така че не е необходимо да го излагате на целия интернет. Агентът координира внедряването, като изисква нови промени от GitLab, вместо GitLab да изпраща актуализации към клъстера. Без значение кой GitOps метод използвате, GitLab е точно за вас.

Моля, имайте предвид, че това е първото издание на агента. В момента сме фокусирали GitLab Kubernetes Agent върху конфигурирането и управлението на внедряването чрез код. Някои съществуващи функции за интегриране на Kubernetes, като табла за внедряване и управлявани от GitLab приложения, все още не се поддържат. Предполагамече тези възможности ще бъдат добавени към агента в бъдещи версии, както и нови интеграции, фокусирани върху сигурността и съответствието.

GitLab Kubernetes Agent Документация и оригинален билет.

Дайте на потребителите разрешения за внедряване без достъп до код

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

Преди това системата за разрешения в GitLab не ви позволяваше да разпределите правилно отговорностите във вашия екип между тези, които отговарят за разработката, и тези, които отговарят за внедряването. С пускането на GitLab 13.4 можете да дадете разрешение за потвърждаване на заявки за сливане за внедряване, както и за действително внедряване на кода на хора, които не пишат код, като същевременно не им предоставяте достъп за поддържащ (в руската локализация на GitLab, „поддържащ ").

Документация за достъп до околната среда и оригинален епос.

Център за сигурност

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Сигурен

Преди това управлението на уязвимости на ниво инстанция беше ограничено както във функционалността, така и в гъвкавостта. Интерфейсът беше една страница, която комбинира подробности за уязвимостта, графики на показатели и настройки. Няма много място за разработване на тези функции или използване на други функции за сигурност.

Направихме фундаментални промени в управлението на сигурността и прозрачността на сигурността в GitLab. Панелът за сигурност на екземпляра е трансформиран в цял център за сигурност. Най-голямата промяна е въвеждането на нова структура на менюто: вместо една страница, сега виждате панела за контрол на сигурността, доклада за уязвимости и секцията с настройки отделно. Въпреки че функционалността не се е променила, разбиването й ще позволи подобрения в този раздел, които иначе биха били трудни. Той също така поставя началото на други функции, свързани със сигурността, които да бъдат добавени в бъдеще.

Специалният раздел за докладване на уязвимости вече има повече място за показване на важни подробности. Тук се събират уязвимостите, които в момента са в списъка с уязвимости на проекта. Преместването на джаджи с показатели за уязвимост в отделен раздел създава удобен контролен панел за сигурност. Сега това е платно за бъдещи визуализации - не само за управление на уязвимости, но и за всякакви показатели, свързани със сигурността. И накрая, специална зона за настройки създава общо пространство за всички настройки за сигурност на ниво инстанция, а не само за управление на уязвимости.

Документация на центъра за сигурност на екземпляра и оригинален епос.

Превключващите функции вече са в GitLab Starter

(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО) Етап на цикъла на DevOps: Издаване

GitLab 11.4 беше пуснат алфа версия на превключваеми функции. В 12.2 въведохме стратегии за тях процент потребители и по потребителско име, а в 13.1 доп потребителски списъци и определяне на стратегии за различни среди.

По-рано тази година GitLab се ангажира да преместете 18 функции в отворен код. В тази версия завършихме прехвърлянето на превключваеми функции към плана Starter и ще продължим да ги прехвърляме към Core с Git Lab 13.5. Радваме се да предоставим тази функция на повече потребители и искаме да знаем как ще я използвате.

Документация за превключваеми функции и оригинален билет.

Бърза навигация от лентата за търсене

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) наличност

Понякога, когато навигирате през GitLab, искате да отидете направо към конкретен проект вместо страницата с резултати от търсенето.

С глобалната лента за търсене можете бързо да навигирате до най-новите билети, групи, проекти, настройки и теми за помощ. Можете дори да използвате клавишна комбинация /за да преместите курсора в лентата за търсене, за да навигирате GitLab още по-ефективно!

Търсете документация за автоматично попълване и оригинален билет.

Показване на покритието на кода в разликите в исканията за сливане

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Когато преглеждате заявка за сливане, може да е трудно да се определи дали промененият код е обхванат от тестове на единици. Вместо това рецензентите могат да разчитат на цялостното покритие и да изискват то да бъде увеличено, преди да одобрят искането за сливане. Това може да доведе до хаотичен подход за писане на тестове, който всъщност не подобрява качеството на кода или покритието на теста.

Сега, когато преглеждате diff заявка за сливане, ще видите визуално показване на покритието на кода. Новите маркировки ще ви позволят бързо да разберете дали промененият код е обхванат от единичен тест, което ще помогне за ускоряване на прегледите на кода и времето за обединяване и внедряване на нов код.

Благодаря Фабио Хусер и Siemens за тази функция!

Документация за показване на кодово покритие с тестове и оригинален билет.

Още среди и проекти в панела за среди

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

От пускането на GitLab 12.5 с панели за околната среда можете да проследявате състоянието на среди, но не повече от седем среди в три проекта. Подобрихме този панел във версия 13.4, като го пагинирахме, за да ви помогнем да поддържате и управлявате вашите среди в мащаб. Сега можете да видите повече среди в повече проекти.

Документация на панела за среди и оригинален билет.

GitLab поема контрола над GitLab Terraform Provider

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Конфигуриране

Наскоро ние получи права за поддръжка на доставчика GitLab Terraform и планирайте подобрете го в предстоящите версии. През последния месец приехме 21 заявки за сливане и затворихме 31 заявки, включително някои дългогодишни грешки и липсващи функции, като напр. поддръжка за клъстери от инстанции... Можеш научете повече за доставчика GitLab Terraform в документацията на Terraform.

Документация на GitLab Terraform доставчик и оригинален билет.

Тестване на Fuzz API със спецификации на OpenAPI или HAR файл

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Сигурен

API fuzz тестването е чудесен начин да намерите грешки и уязвимости във вашите уеб приложения и API, които други скенери и методи за тестване може да пропуснат.

Fuzzing API тестването в GitLab ви позволява да предоставите OpenAPI v2 спецификация или HAR файл вашето приложение и след това автоматично генерира произволни входни данни за крайно тестване и търсене на грешки. Резултатите се показват незабавно във вашия конвейер.

Това е първото ни издание на тестване на API за размиване и ще се радваме да чуем какво мислите. За Fuzzing тестване имаме още на склад много идеи, която ще базираме на пускането на тази функция.

Документация за тестване на API Fuzz и оригинален епос.

Визуализирайте новите графики в панела с показатели

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

В миналото създаването на графика в таблото за управление на показателите в GitLab беше трудна задача. След като сте създали показателя в YAML файла на панела, сте направили промени в master, без да можете да проверите дали току-що създадената графика работи точно както искате. Започвайки с тази версия, можете да преглеждате промените, докато създавате графика, като получавате представа за резултата, преди да изпратите промени в .yaml файла на панела.

Документация за добавяне на нова графика към панел и оригинален билет.

Данни за покритие на кода с тестове за всички проекти на групата

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Когато управлявате голям брой проекти в GitLab, имате нужда от един източник на информация за това как покритието на кода се променя в проектите с течение на времето. Преди показването на тази информация изискваше досадна и отнемаща време ръчна работа: трябваше да изтеглите данни за покритието на кода от всеки проект и да ги комбинирате в таблица.

Във версия 13.4 стана възможно лесно и бързо компилиране в .csv архивирайте всички данни за покритието на кода за всички проекти на групата или за избрани проекти. Тази функция е MVC, тя ще бъде последвана от възможността начертайте средното покритие във времето.

Документация за анализ на хранилище и оригинален билет.

Поддръжка за нови езици за пълно тестване на fuzz

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Сигурен

Тази версия въвежда поддръжка за няколко нови езика за fuzz тестване, насочено към пълно покритие.

Сега можете да проучите всички възможности за fuzz тестване във вашите Java, Rust и Swift приложения и да откриете грешки и уязвимости, които други скенери и методи за тестване може да пропуснат.

Документация за поддържаните езици за fuzz тестване и оригинален епос.

Известия на главната страница на среди

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

Страницата за среди показва общото състояние на вашите среди. В тази версия подобрихме тази страница, като добавихме показване на предупреждения. Задействаните сигнали заедно със състоянието на вашите среди ще ви помогнат да предприемете коригиращи действия по-бързо.

Документация за преглед на скорошни предупреждения в среди и оригинален билет.

Вложените тръбопроводи вече могат да изпълняват свои собствени вложени тръбопроводи

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Когато се използват вложени тръбопроводи, стана възможно да се изпълняват нови тръбопроводи в дъщерни тръбопроводи. Допълнителното ниво на дълбочина може да бъде полезно, ако имате нужда от гъвкавостта за генериране на променлив брой тръбопроводи.

Преди това, когато се използваха вложени тръбопроводи, всеки дъщерен тръбопровод изискваше задание за задействане, което беше ръчно дефинирано в родителския тръбопровод. Сега можете да създавате вложени тръбопроводи, които динамично ще стартират произволен брой нови вложени тръбопроводи. Например, ако имате monorepo, можете динамично да генерирате първия вложен конвейер, който сам ще създаде необходимия брой нови конвейери въз основа на промените в клона.

Документация за вложени тръбопроводи и оригинален билет.

Подобрена навигация между родителски и вложени канали

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Преминаването между родителски и вложени тръбопроводи преди това не беше много удобно - отнемаха много кликвания, за да се стигне до желания тръбопровод. Също така не беше лесно да се разбере коя точно работа е започнала този тръбопровод. Сега ще бъде много по-лесно да видите връзките между родителски и вложени конвейери.

Документация за вложени тръбопроводи и оригинален билет.

Работа с паралелна матрица показва съответните променливи в длъжността

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Ако сте използвали матрица на задачите, може би сте забелязали, че е трудно да се определи коя матрична променлива е използвана за коя работа, тъй като имената на задачите изглеждаха така matrix 1/4. Във версия 13.4 ще видите съответните стойности на променливите, които са били използвани в това задание, вместо общото име на заданието. Например, ако целта ви е да отстраните грешки за x86 архитектурата, тогава задачата ще бъде извикана matrix: debug x86.

Документация за работа на паралелна матрица и оригинален билет.

Други подобрения в GitLab 13.4

Свързване на акаунт в Atlassian

(CORE, STARTER, PREMIUM, ULTIMATE) Етап на цикъла на DevOps: Управление

Потребителите на GitLab вече ще могат да свързват своите акаунти в GitLab с акаунт в Atlassian Cloud. Това ще ви позволи да влезете в GitLab с вашите идентификационни данни за Atlassian, както и да поставите основата за бъдещи подобрения на интеграцията. Gitlab с Jira и с други продукти от линията Atlassian.

Документация за интегриране на Atlassian и оригинален билет.

Експортирайте списък с всички ангажименти за сливане

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Управление

Организациите за съответствие се нуждаят от начин да покажат на одиторите цялостен поглед върху компонентите, свързани с всяка дадена производствена промяна. В рамките на GitLab това означава събиране на всичко на едно място: заявки за сливане, билети, конвейери, сканирания за сигурност и други данни за ангажименти. Досега или трябваше ръчно да събирате това в GitLab, или да настройвате вашите инструменти за събиране на информация, което не беше много ефективно.

Сега можете програмно да улавяте и експортирате тези данни, за да посрещнете вашите одитни или други нужди. За да експортирате списък с всички ангажименти за сливане за текущата група, трябва да отидете до панели за съответствие и щракнете върху бутона Списък на всички ангажименти за сливане. Полученият файл ще съдържа всички ангажименти на заявка за сливане, техния автор, свързан идентификатор на заявка за сливане, група, проект, комититори и друга информация.

Документация за създаване на отчет и оригинален билет.

Изброяване и управление на лични токени за достъп чрез API

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Управление

Управлението на достъпа до пространството от имена на GitLab е важна част от усилията за съответствие. От принципите на най-малка привилегия до деактивирането на времеви достъп, може да има няколко изисквания, свързани с личните токени за достъп в GitLab. За да улесним поддържането и управлението на всички тези потребителски идентификационни данни във вашето пространство от имена, ние предоставихме възможността да изброим всички токени за частен достъп и по избор отказвам достъп чрез API.

Тези подобрения на API на GitLab позволяват на потребителите да изброяват и отменят своите лични токени за достъп, а на администраторите да изброяват и отменят токените на своите потребители. Вече ще бъде по-лесно за администраторите да виждат кой има достъп до тяхното пространство от имена, да вземат решения за достъп въз основа на потребителски данни и да отменят лични токени за достъп, които може да са били компрометирани или които попадат извън политиките за контрол на достъпа на компанията.

Документация за токен за личен достъп и оригинален билет.

Свързани билети и други функции вече са в GitLab Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: План

Преди няколко месеца обявихме план за превеждане на 18 функции в отворен код. Работейки, за да изпълним това обещание, ние направихме свързани билети, експортиране на билети в CSV и режим на фокусиране на таблото със задачи (в руската локализация на GitLab „дискусионна дъска“), наличен в основния план. Това се отнася само за връзки от типа „свързани с“, връзките от типа „блокове“ и „блокове“ остават в платените планове.

Свързана документация за билети и оригинален билет.

Показване на името на изходния клон в страничната лента на заявката за сливане

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Когато преглеждате промени в кода, дискусии и ангажименти на заявки за сливане, често е желателно да проверите клона локално за по-задълбочен преглед. Намирането на името на клона обаче става все по-трудно, тъй като към описанието на заявката за сливане се добавя повече съдържание и страницата трябва да се превърта все повече и повече.

Добавихме името на клона към страничната лента на заявката за сливане, което го направи достъпно по всяко време и елиминира необходимостта от превъртане през цялата страница. Подобно на връзката за заявка за сливане, разделът за клон на източника съдържа удобен бутон "копиране".

Благодаря Итън Ризор за огромния принос в развитието на тази функция!

Документация за искане за сливане и оригинален билет.

Индикация за наличието на свити файлове в diffs на искане за сливане

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Заявките за сливане, които добавят промени към множество файлове, понякога свиват големи файлови разлики, за да подобрят производителността на дисплея. Когато това се случи, е възможно случайно да пропуснете файл при преглед, особено при заявки за сливане с голям брой файлове. Започвайки с версия 13.4, заявките за сливане ще маркират разлики, които съдържат сгънати файлове, така че няма да пропуснете тези файлове по време на процеса на преглед на кода. За още по-голяма яснота планираме да добавим подчертаване на тези файлове в бъдеща версия. Следете за актуализации на gitlab билет №16047.

Документация за свити файлове в разл. заявка за сливане и оригинален билет.

Предупреждение за наличието на свити файлове в diff заявка за сливане

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

В раздела diff за искане за сливане големите файлове се свиват, за да се подобри производителността. Въпреки това, когато преглеждате кода, някои файлове може да бъдат пропуснати, когато проверяващият превърта през списъка с файлове, тъй като всички големи файлове са свити.

Добавихме видимо предупреждение в горната част на страницата за разлика в искането за сливане, за да информираме потребителите, че в този раздел има обединен файл. По този начин няма да пропуснете никакви промени в заявката за сливане по време на прегледа.

Документация за свити файлове в разл. заявка за сливане и оригинален билет.

Автоматично възстановяване на клъстерното хранилище Gitaly

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Преди това, когато основният възел на клъстер Gitaly падна, хранилищата на този възел бяха маркирани като само за четене. Това предотврати загуба на данни в ситуации, при които има промени на възела, които все още не са били репликирани. Когато възелът се свърза отново, GitLab не се възстанови автоматично и администраторите трябваше ръчно да стартират процеса на синхронизиране или да се примирят със загуба на данни. Други ситуации също могат да доведат до остарели или само за четене хранилища, като неуспех на задание за репликация на вторичен възел. В този случай хранилището остава неактуално, докато не бъде извършена следващата операция за запис, която ще стартира заданието за репликация.

За да разрешите този проблем Префект сега планира задание за репликация, когато открие остаряло хранилище на един възел и най-новата версия на хранилище на друг. Това задание за репликация поддържа хранилището актуално автоматично, елиминирайки необходимостта от ръчно възстановяване на данни. Автоматичното възстановяване също гарантира, че вторичните възли се актуализират бързо, ако задание за репликация е неуспешно, вместо да чака следващата операция за запис. Тъй като много клъстери на Gilaly съхраняват голям брой хранилища, това значително намалява времето, което администраторите и инженерите по надеждност изразходват за възстановяване на данни след грешка.

В допълнение, автоматичната корекция започва да репликира хранилища на всеки нов Gitaly възел, добавен към клъстера, елиминирайки ръчната работа по добавяне на нови възли.

Gitaly документация за възстановяване на данни и оригинален билет.

Маркирайте задачата като изпълнена на страницата за дизайн

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Ефективната комуникация в GitLab се основава на списъци със задачи. Ако сте били споменати в коментар, изключително важно е да можете да стигнете до задача и или да започнете да правите нещо, или да го маркирате като изпълнено. Също така е важно да можете да си възложите задача, когато трябва да работите върху нещо или да се върнете към него по-късно.

Преди не можете да добавяте задачи или да ги маркирате като завършени, докато работите върху проекти. Това сериозно наруши ефективността на комуникацията между продуктовите екипи, тъй като задачите за вършене са критичен елемент от работния процес в GitLab.

Във версия 13.4 дизайнът наваксва коментарите на тикетите при използването на задачи, което ги прави по-последователни и ефективни.

Документация за добавяне на задачи към проекти и оригинален билет.

Подобрено ръководство за отстраняване на неизправности за CI/CD

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Подобрихме GitLab CI/CD Ръководството за отстраняване на неизправности, като добавихме допълнителна информация за често срещани проблеми, които може да срещнете. Надяваме се, че подобрената документация ще бъде ценен ресурс, който да ви помогне бързо и лесно да настроите и стартирате GitLab CI/CD.

Документация за отстраняване на проблеми с CI/CD и оригинален билет.

Заявките за сливане вече не се премахват от опашката за сливане

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Преди това заявките за сливане можеха случайно да изпаднат от опашката за сливане поради закъснели коментари. Ако заявка за сливане вече е била в опашката и някой е добавил коментар към нея, който създава нова неразрешена дискусия, заявката за сливане се счита за неподходяща за сливане и отпада от опашката. Сега, след добавяне на заявка за сливане към опашката за сливане, могат да се добавят нови коментари без страх от нарушаване на процеса на сливане.

Обединяване на документация за опашка и оригинален билет.

Показване на стойността на покритие на кода за задание в заявка за сливане

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Разработчиците трябва да могат да видят стойността на покритието на кода, след като конвейерът е завършен – дори в сложни сценарии, като например изпълнение на конвейер с множество задания, които трябва да бъдат анализирани, за да се изчисли стойността на покритие. Преди това приспособлението за заявка за сливане показваше само средната стойност на тези стойности, което означаваше, че трябва да отидете на страницата за работа и да се върнете към заявката за сливане, за да получите междинни стойности на покритие. За да ви спестим време и тези ненужни стъпки, ние направихме джаджата да показва средната стойност на покритие, нейните промени между целевия и изходния клонове и подсказка, която показва стойността на покритие за всяка задача, въз основа на която е изчислена средната стойност .

Документация за разбор на покритие на код и оригинален билет.

Премахване на пакети от регистъра на пакетите при преглед на група

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Пакет

Регистърът на пакетите GitLab е място за съхраняване и разпространение на пакети в различни формати. Когато вашият проект или група има много пакети, трябва бързо да идентифицирате неизползваните пакети и да ги премахнете, така че хората да не ги изтеглят. Можете да премахнете пакети от вашия регистър чрез API на пакети или чрез потребителския интерфейс на регистъра на пакетите. Досега обаче не можехте да изтривате пакети, когато преглеждате група през потребителския интерфейс. В резултат на това трябваше да премахнете излишните пакети за всеки проект, което беше неефективно.

Вече можете да премахвате пакети, когато преглеждате регистъра на пакетите на група. Просто отидете на страницата на регистъра на пакетите на групата, филтрирайте пакетите по име и премахнете всички, които не ви трябват.

Документация за премахване на пакети от регистъра на пакетите и оригинален билет.

Мащабиране на Conan пакети до ниво проект

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Пакет

Можете да използвате хранилището на GitLab Conan, за да публикувате и разпространявате C/C++ зависимости. Преди това обаче пакетите можеха да бъдат мащабирани само до ниво на инстанция, тъй като името на пакета Conan можеше да бъде максимум 51 знака. Ако искате да публикувате пакет от подгрупа като gitlab-org/ci-cd/package-stage/feature-testing/conan, беше почти невъзможно да се направи.

Вече можете да мащабирате пакетите Conan до ниво проект, което улеснява публикуването и разпространението на зависимостите на вашия проект.

Документация за публикуване на пакети Conan и оригинален билет.

Поддръжка за нови мениджъри на пакети и езици за сканиране на зависимости

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Сигурен

Ние сме развълнувани да добавим сканиране на зависимости за проекти с C, C++, C# и .Net код, които използват NuGet 4.9+ или мениджърите на пакети Conan към нашия списък. поддържани езици и рамки. Вече можете да активирате сканиране на зависимости като част от защитения етап, за да проверите зависимостите, добавени чрез мениджъри на пакети, за известни уязвимости. Намерените уязвимости ще бъдат показани във вашата заявка за сливане заедно с тяхното ниво на сериозност, така че да знаете преди сливането какви рискове носи нова зависимост. Можете също така да персонализирате вашия проект според нуждите потвърждение на заявка за сливане за зависимости с критични (Critical), високи (High) или неизвестни (Unknown) уязвимости.

Документация за поддържани езици и мениджъри на пакети и оригинален епос.

Известия при промяна на настройката на заявката за сливане на „Сливане при успешно завършване на конвейера“

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

Преди това, когато задавахте настройката за искане за сливане Обединете, когато конвейерът приключи (Обединяване при успех на тръбопровода, MWPS) не е изпратено известие по имейл. Трябваше ръчно да проверите състоянието или да изчакате сливането да бъде уведомено. В тази версия имаме удоволствието да представим приноса на потребителя @ravishankar2kool, който реши този проблем чрез добавяне на автоматични известия към всички, които са се абонирали за искането за сливане, когато рецензентът промени настройката за сливане на MWPS.

Документация относно известията за събития при искане за сливане и оригинален билет.

Създаване на EKS клъстери с дефинирана от потребителя версия на Kubernetes

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Конфигуриране

Потребителите на GitLab вече могат да избират версията на Kubernetes, която ще бъде предоставена от EKS; можете да избирате между версии 1.14-1.17.

Документация за добавяне на EKS клъстери и оригинален билет.

Създаване на инциденти като типове билети

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

Не всеки възникнал проблем незабавно задейства предупреждения: Потребителите съобщават за прекъсвания, а членовете на екипа проучват проблеми с производителността. Инцидентите вече са форма на билет, така че вашите екипи могат бързо да ги създават като част от познат работен процес. Кликнете Нова задача от всяко място в GitLab и на полето Тип изберете Инцидент.

Документация за ръчно създаване на инциденти и оригинален билет.

Споменаване на GitLab предупреждения в Markdown

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

Подобрихме сигналите на GitLab, като добавихме нов тип споменаване специално за тях във версията на Markdown на GitLab, което улеснява споделянето и споменаването на сигнали. Използвайте ^alert#1234да споменавате предупреждението във всяко поле Markdown: в инциденти, билети или заявки за сливане. Също така ще ви помогне да дефинирате проблеми, които са създадени от предупреждения, а не от билети или заявки за сливане.

Документация за управление на инциденти и оригинален билет.

Преглед на натоварването за предупреждение за инцидент

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

Описанието на предупреждението съдържа информация от решаващо значение за диагностиката и възстановяването на повреда и тази информация трябва да бъде лесно достъпна, така че да не се налага да превключвате инструменти или раздели, докато работите за разрешаване на инцидент. Инцидентите, създадени от предупреждения, показват пълното описание на предупреждението в раздел Подробности за предупреждение.

75% по-бързо разширено търсене

(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО) наличност

GitLab, като едно приложение, има уникалната способност да прави бързо откриване на съдържание в целия работен процес на DevOps. В GitLab 13.4 разширеното търсене връща резултати 75% по-бързо, когато го направи ограничено до определени пространства от имена и проекти, като на GitLab.com.

По-бърза разширена документация за търсене и оригинален билет.

Преглед на отдалечени проекти за администратори

(CORE, STARTER, PREMIUM, ULTIMATE) Етап на цикъла на DevOps: Управление

Възможността за забавяне на изтриването на проект беше въведен в 12.6. Преди обаче не беше възможно да видите всички проекти, които чакат да бъдат изтрити, на едно място. Администраторите на персонализирани екземпляри на GitLab вече могат да преглеждат всички чакащи проекти за изтриване на едно място, заедно с бутони за лесно възстановяване на тези проекти.

Тази функция дава на администраторите по-голям контрол върху изтриването на проекти, като събира цялата необходима информация на едно място и предоставя възможност за отмяна на нежелани изтривания.

Благодаря Ашеш Видют (@asheshvidyut7) за тази функция!

Документация за изтриване на проекти и оригинален билет.

Добавена е поддръжка за правила за групово насочване към API

(СТАРТЕР, ПРЕМИУМ, КРАЙЕН, БРОНЗ, СРЕБРО, ЗЛАТО) Етап на цикъла на DevOps: Управление

Преди груповите правила за натискане можеха да бъдат конфигурирани само чрез посещение на всяка група поотделно чрез потребителския интерфейс на GitLab и прилагане на тези правила. Вече можете да управлявате тези правила чрез API, за да поддържате персонализираните си инструменти и автоматизацията на GitLab.

Документация за групови правила за натискане и оригинален билет.

Отменете лични токени за достъп за самостоятелно управлявано хранилище на идентификационни данни

(КРАЙНО) Етап на цикъла на DevOps: Управление

Съхранение на идентификационни данни предоставя на администраторите информацията, от която се нуждаят, за да управляват потребителските идентификационни данни за техния екземпляр на GitLab. Тъй като организациите, ориентирани към съответствие, се различават в строгостта на своите политики за управление на идентификационни данни, ние добавихме бутон, който позволява на администраторите да отменят личния маркер за достъп (PAT) на потребителя, ако желаят. Администраторите вече могат лесно да отменят потенциално компрометирани PATs. Тази функция е полезна за организации, които се нуждаят от по-гъвкави опции за прилагане, за да сведат до минимум разсейването на своите потребители.

Документация за съхранение на идентификационни данни и оригинален билет.

Конфигурационен файл за редактора на статичен сайт

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

В GitLab 13.4 въвеждаме нов начин за персонализиране на редактора на статичен сайт. Въпреки че конфигурационният файл не съхранява или извлича никакви настройки в тази версия, ние полагаме основата за бъдещо персонализиране на поведението на редактора. В следващите версии ще добавим към файла .gitlab/static-site-editor.yml параметри за инсталиране базов адрес на сайта, на която съхранява изображения, заредени в редактора, заменяйки настройките за синтаксис на Markdown и други настройки на редактора.

Документация за настройка на редактора на статичен сайт и оригинален епос.

Редактиране на уводната част на файл с помощта на редактора на статичен сайт

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Предната материя е гъвкав и удобен начин за дефиниране на променливи на страници във файлове с данни, които да бъдат обработени от генератора на статичен сайт. Обикновено се използва за задаване на заглавието на страницата, шаблона за оформление или автора, но може да се използва за предаване на всякакъв тип метаданни към генератора при рендиране на страницата в HTML. Включен най-отгоре на всеки файл с данни, преамбюлът обикновено е форматиран като YAML или JSON и изисква последователен и точен синтаксис. Потребителите, които не са запознати със специфични правила за синтаксис, могат по невнимание да въведат невалидно маркиране, което от своя страна може да причини проблеми с форматирането или дори неуспешно изграждане.

Режимът на редактиране WYSIWYG на редактора на статичен сайт вече премахва въведението от редактора, за да предотврати тези грешки при форматиране. Това обаче ви предпазва от промяна на стойностите, съхранени в тази част, без да се върнете към редактиране в режим на източник. В GitLab 13.4 можете да получите достъп до всяко поле и да редактирате стойността му в познат интерфейс, базиран на формуляр. Когато натиснете бутон Настройки (Настройки) отваря панел, който показва поле на формуляр за всеки ключ, дефиниран в началото. Полетата се попълват с текущата стойност и за да редактирате някое от тях, просто го въведете в уеб формата. Това редактиране на предговора избягва сложността на синтаксиса и ви дава пълен контрол върху съдържанието, като същевременно гарантира, че крайният изход е форматиран последователно.

Документация за редактор на статичен сайт и оригинален билет.

GitLab за Jira и DVCS Connector вече в Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

За потребителите на Jira в GitLab: Приложение GitLab за Jira и DVCS конектор ви позволяват да показвате информация за GitLab ангажименти и заявки за сливане директно в Jira. В комбинация с нашата вградена интеграция с Jira можете лесно да се движите между двете приложения, докато работите.

Тези функции преди бяха налични само в нашия Premium план, но сега са достъпни за всички потребители!

Документация за интегриране на Jira и оригинален билет.

Гласуване с мнозинство за клъстерни транзакции в Gitaly (бета)

(CORE, STARTER, PREMIUM, ULTIMATE) Етап на цикъла на DevOps: Създаване

Клъстер Gitaly ви позволява да репликирате Git хранилища в множество топли Gitaly възли. Това подобрява толерантността към грешки чрез елиминиране на единични точки на повреда. Транзакционни операции, въведен в GitLab 13.3, кара промените да бъдат излъчвани към всички Gitaly възли в клъстера, но само Gitaly възли, които гласуват в съгласие с основния възел, запазват промените на диска. Ако всички възли на реплика не са съгласни, само едно копие на промяната ще бъде запазено на диска, създавайки единична точка на повреда, докато не завърши асинхронната репликация.

Гласуването с мнозинство подобрява толерантността към грешки, като изисква съгласието на мнозинството (а не всички) от възлите, преди да запишете промените на диска. Ако тази функция за превключване е активирана, записът трябва да успее на множество възли. Несъгласуващите възли се синхронизират автоматично с помощта на асинхронна репликация от тези възли, които са образували кворум.

Документация за настройка на последователност в Gitaly и оригинален билет.

Поддръжка за персонализирана схема за валидиране на JSON в Web IDE

(PREMIUM, ULTIMATE, SILVER, GOLD) Етап на цикъла на DevOps: Създаване

Проекти, при които хората пишат конфигурации във формат JSON или YAML, често са предразположени към проблеми, защото е лесно да направите печатна грешка и да счупите нещо. Възможно е да се напишат инструменти за валидиране, които улавят тези проблеми в CI тръбопровода, но използването на JSON файл със схема може да бъде полезно за предоставяне на документация и съвети.

Членовете на проекта могат да дефинират в своето хранилище пътя до персонализираната схема във файла .gitlab/.gitlab-webide.yml, който указва схемата и пътя до файловете за проверка. Когато конкретен файл бъде качен в Web IDE, допълнителна обратна връзка и проверка ще бъдат видими, за да помогнат за създаването на файла.

Документация за персонализирани схеми в уеб IDE и оригинален билет.

Ограничението за разклонения на насочена ациклична графика (DAG) е увеличено до 50

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Ако използвате тръбопроводи с насочен ацикличен граф (Насочена ациклична графика (DAG)), може да откриете, че има ограничение от 10 задания, които едно задание може да посочи в needs:, твърде грубо. В 13.4 ограничението по подразбиране е увеличено от 10 на 50, за да позволи по-сложни мрежи от връзки между задания във вашите конвейери.

Ако сте администратор на потребителски екземпляр на GitLab, можете да повишите този лимит още повече, като настроите функция за превключване, въпреки че не предлагаме официална поддръжка за това.

Документация по настройке needs: и оригинален билет.

Подобрено поведение needs за пропуснати задачи

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

В някои случаи пропуснато задание в конвейер може погрешно да се счита за успешно за зависимостите, изброени в needs, причинявайки изпълнение на последващи задания, когато не трябва. Това поведение е коригирано във версия 13.4 и needs сега правилно обработва случаи на пропуснати задачи.

Документация по настройке needs и оригинален билет.

Фиксирайте последния артефакт на задание, за да предотвратите изтриването му

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

GitLab вече автоматично заключва последния артефакт от успешна задача и конвейер на всеки активен клон, заявка за сливане или етикет, за да предотврати изтриването му след изтичане. Става все по-лесно да се задават по-агресивни правила за изтичане, за да се изчистят стари артефакти. Това помага за намаляване на потреблението на дисково пространство и гарантира, че винаги имате копие на най-новия артефакт от конвейера.

Документация за изтичане на артефакта и оригинален билет.

CI/CD ръководство за оптимизиране на тръбопровода

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Оптимизирането на CI/CD тръбопровода може да подобри скоростта на доставка и да спести пари. Подобрихме нашата документация с кратко ръководство за извличане на максимума от оптимизирането на тръбопроводите ви.

Документация за подобряване на ефективността на конвейера и оригинален билет.

Доклад от теста, сортиран по статус на теста

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Проверка

Доклад от изпитване на единица е лесен начин да видите резултатите от всички тестове в процес на подготовка. Въпреки това, при голям брой тестове, намирането на неуспешни тестове може да отнеме много време. Други проблеми, които могат да направят отчета труден за използване, включват затруднено превъртане през дълги изходни данни за проследяване и време за закръгляване до нула за тестове, които се изпълняват за по-малко от 1 секунда. Сега по подразбиране отчетът за сортиране на теста първо поставя неуспешните тестове в горната част на отчета и след това сортира тестовете по продължителност. Това улеснява намирането на сривове и дълги тестове. В допълнение, продължителността на теста вече се показва в милисекунди или секунди, което ги прави много по-бързи за четене, а предишните проблеми с превъртането също са разрешени.

Документация за докладване на тест на единица и оригинален билет.

Ограничения за размера на файла, качен в регистъра на пакетите

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Пакет

Вече има ограничения за размера на пакетните файлове, които могат да бъдат качени в регистъра на пакетите на GitLab. Добавени са ограничения за оптимизиране на производителността на регистъра на пакетите и предотвратяване на злоупотреби. Ограниченията зависят от формата на пакета. За GitLab.com максималните размери на файловете са:

• Конан: 250MB
• Maven: 3 GB
• NPM: 300MB
• NuGet: 250MB
• PyPI: 3GB

За персонализирани екземпляри на GitLab, настройките по подразбиране са същите. Въпреки това администраторът може да актуализира ограниченията с Релсови конзоли.

Документация относно ограниченията на размера на файла и оригинален билет.

Използвайте CI_JOB_TOKEN за публикуване на PyPI пакети

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Пакет

Можете да използвате PyPI хранилището на GitLab, за да създавате, публикувате и споделяте Python пакети заедно с изходния код и CI/CD тръбопроводи. Преди това обаче не можехте да се удостоверявате срещу хранилище с предварително дефинирана променлива на средата CI_JOB_TOKEN. В резултат на това трябваше да използвате личните си идентификационни данни, за да актуализирате хранилището на PyPI, или може да сте решили изобщо да не използвате хранилището.

Вече е по-лесно да използвате GitLab CI/CD за публикуване и инсталиране на PyPI пакети с помощта на предварително дефинирана променлива на средата CI_JOB_TOKEN.

Документация за използване на GitLab CI с PyPI пакети и оригинален билет.

DAST профили на скенера при поискване

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: Сигурен

Към DAST сканирането по заявка, което беше въведен в предишната версия, добавени са DAST профили на скенера. Те разширяват опциите за конфигурация за това сканиране, като ви позволяват бързо да създавате множество профили, за да покриете множество типове сканиране. В 13.4 профилът на обхождащия първоначално включва настройка за изтичане на времето за обхождане, която задава колко дълго трябва да работи DAST обхождащият, когато се опитва да открие всички страници на обходен сайт. Профилът също така включва настройка за изтичане на целевия сайт, за да зададете колко време роботът трябва да изчака даден сайт да стане достъпен, преди да прекрати обхождането, ако сайтът не отговори с код за състояние 200 или 300. Докато подобряваме отново и отново тази функция в бъдещите издания към профила на скенера ще бъдат добавени допълнителни опции за конфигуриране.

Документация за профила на скенера DAST и оригинален билет.

Прост конфигурационен файл за пренасочване за GitLab Pages

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Издаване

Ако използвате GitLab Pages и искате да управлявате по-добре URL промените, може би сте забелязали, че не е възможно да управлявате пренасочвания на вашия сайт GitLab Pages. GitLab вече ви позволява да настроите правила за пренасочване на един URL към друг за вашия сайт Pages, като добавите конфигурационен файл към хранилището. Тази функция стана възможна благодарение на приноса на Кевин Барнет (@PopeDrFreud), нашият Ерик Истууд (@MadLittleMods) и GitLab команди. Благодаря на всички за приноса.

Документация за пренасочвания и оригинален билет.

Състояние на Terraform, управлявано от GitLab

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Конфигуриране

Достъпът до предишни версии на състоянието на Terraform е необходим както за съответствие, така и за отстраняване на грешки, ако е необходимо. Поддръжка за управление на версиите на състоянието на Terraform, управлявано от GitLab, се предоставя от GitLab 13.4. Версионирането се активира автоматично за нови файлове със състояние на Terraform. Съществуващите файлове за състояние на Terraform ще бъдат автоматично мигрирани към хранилище с версии в по-късна версия.

Документация за управлявани състояния на GitLab Terraform и оригинален билет.

Важни подробности за докладване на инциденти

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

Когато обработвате инциденти, трябва да можете лесно да определите колко време е бил отворен сигналът и колко пъти е задействано дадено събитие. Тези детайли често са критични при определяне на въздействието върху клиентите и какво първо трябва да направи вашият екип. В новия панел с подробности за инцидента показваме началния час на предупреждението, броя на събитията и връзка към оригиналния сигнал. Тази информация е достъпна за инциденти, които са генерирани от сигнали.

Документация за управление на инциденти и оригинален епос.

Задаване и редактиране на параметъра за тежест на инцидента

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Етап на цикъла на DevOps: Монитор

Измерението Сериозност на инцидента позволява на реагиращите и заинтересованите страни да определят въздействието на прекъсването, както и методите и спешността на реакцията. Тъй като вашият екип споделя резултатите по време на разрешаването на инцидента и възстановяването, той може да промени тази настройка. Вече можете да редактирате сериозността на инцидент в дясната странична лента на страницата с подробности за инцидента и тежестта се показва в списъка с инциденти.

Документация за инцидента и оригинален билет.

Създавайте, редактирайте и изтривайте правила за сигурност на мрежата на контейнера

(КРАЕН, ЗЛАТЕН) Етап на цикъла на DevOps: защита

Това подобрение на редактора на правила за мрежова сигурност на контейнера позволява на потребителите лесно да създават, редактират и изтриват свои собствени правила направо от потребителския интерфейс на GitLab. Функциите на редактора включват режим .yaml за напреднали потребители и редактор на правила с интуитивен интерфейс за начинаещите в мрежовите правила. Можете да намерите нови функции за управление на правилата в раздела Сигурност и съответствие > Управление на заплахи > Правила (Сигурност и съответствие > Управление на заплахи > Политики).

Документация на редактора на мрежови правила и оригинален епос.

Поддръжка за съхранение на Azure blob

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) наличност

GitLab и GitLab Runner вече се поддържат Съхранение на Azure blob, което улеснява стартирането на GitLab услуги на Azure.

GitLab екземплярите поддържат Azure за всички видове съхранение на обекти, включително LFS файлове, CI артефакти и резервни копия. За да настроите хранилището на Azure blob, следвайте инструкциите за инсталиране Омнибус или Диаграма на кормилото.

Процесорите за работа на GitLab също поддържат Azure за съхранение разпределен кеш. Съхранението на Azure може да се конфигурира с помощта на секцията [runners.cache.azure].

Документация за съхранение на Azure blob и оригинален билет.

Омнибус ARM64 пакети за Ubuntu и OpenSUSE

(CORE, STARTER, PREMIUM, ULTIMATE) наличност

В отговор на нарастващото търсене на поддръжка за работа на GitLab върху 64-битова ARM архитектура, с удоволствие обявяваме наличието на официален ARM64 пакет. Ubuntu 20.04 април, Omnibus. Огромни благодарности на Zitai Chen и Guillaume Gardet за невероятния им принос – техните заявки за сливане бяха ключови!

За да изтеглите и инсталирате пакета за Ubuntu 20.04, отидете на нашия страница за инсталиране и изберете Ubuntu.

Пакетна документация за ARM64 и оригинален билет.

Поддръжка за удостоверяване на смарт карта за диаграма GitLab Helm

(PREMIUM, ULTIMATE) наличност

Смарт карти, като карти за споделен достъп (CAC), вече могат да се използват за удостоверяване на инстанция на GitLab, внедрена чрез Helm chart. Смарт картите се удостоверяват спрямо локална база данни с помощта на X.509 сертификати. С това поддръжката на смарт карти с Helm chart вече е в съответствие с поддръжката на смарт карти, налична в внедряванията на Omnibus.

Документация за настройките за удостоверяване на смарт карта и оригинален билет.

Подробни бележки по версията и инструкции за надграждане/инсталиране могат да бъдат намерени в оригиналната публикация на английски: GitLab 13.4 пуснат с Vault за CI променливи и Kubernetes Agent.

Работи върху превода от английски cattidourden, maryartkey, айнонеко и ришавант.

Източник: www.habr.com