# Вышел релиз 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 Agent. Специалистите по експлоатация могат да разгръщат клъстери Kubernetes от GitLab, без да е необходимо да отварят достъп до своя клъстер за целия интернет. Също така представяме автоматична поддръжка на версии за новите файлове с Terraform състояние с управлявано състояние на Terraform в GitLab за подкрепа на съответствие с изискванията и удобство при отстраняване на грешки. И накрая, контролният панел за сигурност в инстанса се е трансформирал в център за сигурност на GitLab с отчети за уязвимости и настройки за сигурност.

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

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

Проекти с отворен източник

Представяме покритие на кода в дифовете на мърж-исканията, което добави MVP на този месец, Fabio Huser. Уведомленията за покритие с юнит тестове на променения код дават на разработчиците визуална представа за покритие на кода при преглед; тази информация помага за ускоряване на прегледа и намаляване на времето за мърж и разгръщане на нов код. А ние също преместихме управлявани функционалности (feature flags) в Starter и планираме да ги преместим в Core в релиза 13.5.

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

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

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

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

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

MVP на този месец — Fabio Huser

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

Основни функции на релиза GitLab 13.4

Използвайте ключове HashiCorp Vault в CI задачи

(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 можете да предоставите разрешения за одобрение на merge заявки за разгръщане, както и за действителното разгръщане на код на хора, които не пишат код, без да им предоставяте права на достъп на мейнтейнар (в българската локализация на GitLab

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

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

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

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

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

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

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

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

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

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

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Достъпност

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

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

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

Показване на покритието на кода в диференците на заявките за обединение

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

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

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

Благодаря Fabio Huser и Siemens за тази функция!

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

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

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

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

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

GitLab прие управлението на провайдера GitLab Terraform

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

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

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

Фазинг тестване на API със спецификации OpenAPI или HAR файл

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

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

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

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

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

Предварителен преглед на новите графики на таблото за метрики

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Monitor

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

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

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

(PREMIUM, ULTIMATE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

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

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

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

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

Уведомления на началната страница на средите

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

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

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

Вложените конвейери сега могат да задействат своите вложени конвейери

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE) Фаза на DevOps цикъл: Manage

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

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

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

(ULTIMATE, GOLD) Фаза на DevOps цикъл: Manage

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

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

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

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

(ULTIMATE, GOLD) Фаза на DevOps цикъл: Manage

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

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

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

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

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

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

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

Показване на името на оригиналния клон в страничната лента на мерж-реквеста

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

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

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

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

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

Указание за наличието на свити файлове в дифовете на мерж-реквеста

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

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

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

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

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

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

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

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

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

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

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

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

Освен това, автоматичната поправка стартира репликация на репозитории на всяка нова нода Gitaly, добавена към клъстера, което освобождава от ръчната работа при добавяне на нови ноди.

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

Маркирайте задачата to-do като завършена на страницата за дизайн

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

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

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

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

Мерж-реквестите вече не излизат от опашката за мердж

(PREMIUM, ULTIMATE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уведомления при промяна на настройката на мерж-реквеста на ‘Мержи при успешен завършек на конвейера’

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

По-рано, когато задавахте настройка на мерж-реквеста Мержи, когато конвейера завърши (Merge When Pipeline Succeeds, 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 цикъла: Monitor

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

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

Споменаване на известия в GitLab в Markdown

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Monitor

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Monitor

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

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

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Достъпност

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE) Фаза на DevOps цикъл: Manage

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

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

Благодаря Ashesh Vidyut (@asheshvidyut7) за тази функция!

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

Поддръжка на правила за пуш в API за групи

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Фаза на DevOps цикъл: Manage

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

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

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

(ULTIMATE) Фаза на DevOps цикъл: Manage

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

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

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

(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: Създаване

Уводната част (front matter) е гъвкав и удобен начин за определяне на променливи на страницата в файлове с данни, предназначени за обработка от генератора на статични сайтове. Обикновено се използва за задаване на заглавие на страницата, шаблон на макета или автор, но може да се използва и за предаване на всякакъв тип метаданни на генератора при рендериране на страницата в 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 Connector позволяват показването на информация за комити и мърдж реквести от 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 ще бъде налична допълнителна обратна връзка и проверка, които ще помогнат за създаването на файла.

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

Максималният брой клонове на насочен ацикличен граф (DAG) е увеличен до 50

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

Забранете последния артефакт на задачата, за да предотвратите неговото изтриване

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

Докладът за тестване е сортиран по статус на теста

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Verify

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

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

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

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

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

• Conan: 250MB
• Maven: 3GB
• NPM: 300MB
• NuGet: 250MB
• PyPI: 3GB

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

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

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

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

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

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

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

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

(ULTIMATE, GOLD) Етап от цикъла 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, добавяйки файл за конфигурация в репозитория. Тази функция стана възможна благодарение на участието на Kevin Barnett (@PopeDrFreud), нашия Eric Eastwood (@MadLittleMods) и екипа на GitLab. Благодаря на всички за приноса.

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

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

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

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

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

Важни детайли за известията за инциденти

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Monitor

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

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

Настройка и редактиране на параметъра за сериозност на инцидента

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стъпка в DevOps цикъла: Monitor

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

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

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

(ULTIMATE, GOLD) Етапът от цикъла DevOps: Защита

Това подобрение на редактора за правила за мрежова сигурност на контейнери позволява на потребителите лесно да създават, редактират и изтриват своите правила директно от потребителския интерфейс на GitLab. Възможностите на редактора включват режим .yaml за опитни потребители и редактор на правила с интуитивен интерфейс за тези, които не са запознати със мрежовите правила. Можете да намерите нови възможности за управление на правилата в раздел Сигурност и съответствие > Управление на заплахи > Политики (Security & Compliance > Threat Management > Policies).

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

Поддръжка на Azure за хранилище на blob-обекти

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Достъпност

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

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

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

Документация за използване на Azure BLOB хранилище и оригиналния тикет.

Omnibus 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 chart

(PREMIUM, ULTIMATE) Достъпност

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

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

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

Преводът от английски беше извършен от cattidourden, maryartkey, ainoneko и rishavant.

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