Излезе версия 13.4 с хранилище HashiCorp за променливи CI, Kubernetes Agent и център за сигурност, както и превключваеми функции в Starter
В GitLab винаги мислим как да помогнем на потребителите да намалят рисковете, да повишат ефективността и скоростта на доставките на любимата ви платформа. Този месец добавихме много полезни нововъведения, които разширяват възможностите за сигурност, намаляват броя на уязвимостите, увеличават ефективността, опростяват работата с GitLab и помагат на екипа ви да доставя функции още по-бързо. Надяваме се основните функции на версията, а също така 53 други нови функции, добавени в тази версия.
Разширени възможности за сигурност
Стремим се да добавяме няколко нови функции към GitLab DevSecOps всеки месец и тази версия не е изключение. в рамките на изграждането и разгръщането. Освен това организациите, които искат да поддържат разделение на отговорностите за разгръщане на код, вече могат . Тази роля съответства и ще позволи потвърждаване на мерж-реквестове (в българската локализация на GitLab „кандидатури за сливане“) и разгръщане на код в защитени среди, без да се предоставя достъп за промяна на самия код.
Още един начин за намаляване на рисковете е използването на новия . Специалистите по експлоатация могат да разгръщат клъстери Kubernetes от GitLab, без да е необходимо да отварят достъп до своя клъстер за целия интернет. Също така представяме автоматична поддръжка на версии за новите файлове с Terraform състояние с за подкрепа на съответствие с изискванията и удобство при отстраняване на грешки. И накрая, контролният панел за сигурност в инстанса се е трансформирал в с отчети за уязвимости и настройки за сигурност.
По-удобна и ефективна работа с GitLab
Подобрихме нашето глобално търсене, добавяйки в него , което позволява лесно преминаване към последните тикети, групи, проекти, настройки и секции от справката. Радваме се да обявим, че в GitLab Pages за пренасочване на отделни страници и директории в сайта, което позволява на потребителите по-ефективно да разгръщат своите сайтове. А на тези, които искат да получават разширена информация за разгръщането, този релиз позволява !
Проекти с отворен източник
Представяме , което добави . Уведомленията за покритие с юнит тестове на променения код дават на разработчиците визуална представа за покритие на кода при преглед; тази информация помага за ускоряване на прегледа и намаляване на времето за мърж и разгръщане на нов код. А ние също и планираме .
А това е само началото!
Както винаги, в обобщението е твърде малко място, а страхотни функции в релиза 13.4 има много. Ето още няколко:
- .
Ако искате предварително да разберете какво ви очаква в следващия релиз, вижте .
.
на този месец —
Fabio направи значителен в — функция, която много дълго време се очакваше от общността на GitLab. Това е наистина важен принос с нетривиални промени, които изискваха постоянна съвместна работа с членовете на екипа на GitLab и засягат множество области на проекта, като UX, фронтенд и бекенд.
Основни функции на релиза GitLab 13.4
Използвайте ключове HashiCorp Vault в CI задачи
(PREMIUM, ULTIMATE, SILVER, GOLD)
В релиза 12.10 GitLab представи възможността да получавате и предавате ключове в CI задачи с помощта на обработчика на задачи на GitLab (GitLab runner). Сега разширяваме , добавяйки нова синтаксис secrets в файла .gitlab-ci.yml. Това ще улесни настройките и употребата на хранилището HashiCorp с GitLab.
и .
Представяме GitLab Kubernetes Agent
(PREMIUM, ULTIMATE)
Интеграцията на GitLab с Kubernetes отдавна позволява разгръщането на Kubernetes клъстери без необходимост от ръчна конфигурация. Много потребители харесват простотата на използването на тази комбинация, докато други се сблъскват с някои трудности. За текущата интеграция вашият клъстер трябва да е достъпен от интернет, за да може GitLab да получи достъп до него. За много организации това не е възможно, тъй като те ограничават достъпа до клъстери по съображения за сигурност, спазване на разпоредби или регулации. За да заобиколят тези ограничения, потребителите трябва да създават свои инструменти над GitLab, в противен случай няма да могат да използват тази функция.
Днес представяме GitLab Kubernetes Agent — нов начин за разгръщане на Kubernetes клъстери. Агентът работи вътре във вашия клъстер, така че няма да е необходимо да го отваряте за целия интернет. Агентът координира разгръщането, като запитва нови промени от GitLab, вместо GitLab да изпраща актуализации към клъстера. Без значение коя методология на GitOps използвате, GitLab ще ви бъде от полза.
Обърнете внимание, че това е първият релиз на агента. В момента акцентът на GitLab Kubernetes Agent е върху конфигурирането и управлението на разгръщането чрез код. Някои съществуващи функции на интеграцията с Kubernetes, като дъски за разгръщане и приложения, управлявани от GitLab, все още не се поддържат. , че тези функции ще бъдат добавени в агента в бъдещи релизи, както и нови интеграции, фокусирани върху сигурността и спазването на разпоредбите.
и .
Давайте на потребителите разрешения за разгръщане без достъп до кода
(PREMIUM, ULTIMATE, SILVER, GOLD)
Преди системата за разрешения в GitLab не позволяваше адекватно разделяне на отговорностите в екипа между тези, които отговарят за разработката, и тези, които отговарят за разгръщането. С излизането на GitLab 13.4 можете да предоставите разрешения за одобрение на merge заявки за разгръщане, както и за действителното разгръщане на код на хора, които не пишат код, без да им предоставяте права на достъп на мейнтейнар (в българската локализация на GitLab
и .
Център за сигурност
(ULTIMATE, GOLD)
Предишното управление на уязвимости на ниво инстанция беше ограничено както по функционалност, така и по гъвкавост. Интерфейсът представляваше една страница, обединяваща детайли за уязвимостите, графики на метрики и настройки. Нямаше много пространство за развитие на тези функции или за използване на други средства за защита.
Направихме фундаментални промени в управлението на безопасността и нейната прозрачност в GitLab. Панелът за безопасност на инстанцията се трансформира в цял център за безопасност. Най-голямата промяна е въведението на нова структура на менюто: вместо една страница сега виждате отделно панел за управление на безопасността, отчет за уязвимостите и раздел за настройки. Въпреки че функционалността не се е променила, разбиването на части ще позволи подобрения в този раздел, което в противен случай би било затруднително. Това също създава база за добавяне на бъдещи възможности, свързани с безопасността.
Специалният раздел за отчета за уязвимостите сега има повече пространство за показване на важни детайли. Тук са събрани уязвимости, които в момента са в списъка с уязвимости на проекта. Преместването на уиджетите с метрики за уязвимости в отделен раздел създава удобен панел за управление на безопасността. Сега това е холст за бъдещи визуализации — не само за управление на уязвимостите, но и за всякакви метрики, свързани с безопасността. Най-накрая, отделна област за настройки създава общо пространство за всички настройки за безопасност на ниво инстанция, не само за управление на уязвимостите.
и .
Превключваемите функции вече в GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
В GitLab 11.4 беше пуснат . В 12.2 въведохме стратегии за тях и , а в 13.1 добавихме и за различни среди.
По-рано тази година GitLab пое ангажимент в отворен код. В това издание завършихме преместването на превключваемите функции в плана Starter и ще продължим преместването им в Core с . Радваме се, че можем да предоставим тази възможност на повече потребители и искаме да разберем как ще я използвате.
и .
Бърза навигация от полето за търсене
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Понякога, при навигация в GitLab, искате директно да отидете на конкретен проект, а не на страницата с резултати от търсенето.
С помощта на глобалната панел за търсене можете бързо да преминете към последните тикети, групи, проекти, настройки и раздели за помощ. Можете дори да използвате комбинация от клавиши /, за да преместите курсора към панела за търсене, за да навигирате по-ефективно в GitLab!
и .
Показване на покритието на кода в диференците на заявките за обединение
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При прегледа на заявка за обединение може да бъде трудно да се определи дали промененият код е покрит от юнит тестове. Вместо това преглеждащите могат да разчитат на общото покритие и да изискват да бъде увеличено, преди да потвърдят заявката за обединение. Това може да доведе до нерегламентиран подход при писането на тестове, което всъщност не подобрява качеството на кода или неговото покритие с тестове.
Сега, при преглед на диференцията на заявката за обединение, ще видите визуално представяне на покритието на кода. Новите бележки ще позволят бързо да разберете дали промененият код е покрит от юнит тест, което ще помогне за ускоряване на прегледа на кода и времето за обединение и внедряване на нов код.
Благодаря и Siemens за тази функция!
и .
Повече среди и проекти на панела на средите
(PREMIUM, ULTIMATE, SILVER, GOLD)
С изданието GitLab 12.5 с помощта на можехте да следите състоянието на средите, но не повече от седем среди в три проекта. Подобрихме този панел с изданието 13.4, разделяйки го на страници, за да ви помогнем да поддържате и управлявате средите си в по-голям мащаб. Сега можете да виждате повече среди в повече проекти.
и .
GitLab прие управлението на провайдера GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Неотдавна ние и планираме . За последния месец прифихме 21 мерж-реквеста и затворихме 31 тикета, включително някои дългогодишни грешки и липсващи функции, като . Можете да в документацията по Terraform.
и .
Фазинг тестване на API със спецификации OpenAPI или HAR файл
(ULTIMATE, GOLD)
Фаззинг тестването на API е отличен начин да откриете грешки и уязвимости във вашите уеб приложения и API, които други скенери и тестови методи могат да пропуснат.
Тестването на API чрез фаззинг в GitLab позволява предоставянето на или на вашето приложение и след това автоматично генерира случайни входни данни, предназначени за тестване на краен случай и откриване на грешки. Резултатите веднага се показват в рамките на вашия конвейер.
Това е нашето първо издание на тестване на API чрез фаззинг и ще сме щастливи да чуем какви са вашите мнения. За фаззинг тестването имаме още , на които ще базираме изданието на тази функция.
и .
Предварителен преглед на новите графики на таблото за метрики
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
По-рано създаването на графика на таблото за метрики в GitLab беше сложна задача. След като създадете метрика в YAML файла на таблото, вие правите промени в master, без възможност да проверите дали току-що създаденият график работи точно така, както искате. Започвайки с това издание, можете да преглеждате промените по време на създаването на графика, получавайки представа за резултата преди да изпратите промените в YAML файла на таблото.
и .
Данни за покритие на код с тестове по всички проекти на групата
(PREMIUM, ULTIMATE, SILVER, GOLD)
Когато управлявате много проекти в GitLab, имате нужда от единен източник на информация за това как покритията на кода се променят с времето по всички проекти. По-рано показването на тази информация изискваше уморителна и трудоемка ръчна работа: трябваше да изтеглите данните за покритие на кода от всеки проект и да ги обедините в таблица.
С изданието на 13.4 стана възможно лесно и бързо да се съберат в .csv файл всички данни за покритие на кода по всички проекти на групата или по избрана селекция от проекти. Тази функция е MVC, след което ще последва възможност .
и .
Подкрепа за нови езици за пълно тестване с фаззинг
(ULTIMATE, GOLD)
Това издание представлява подкрепа за няколко нови езика за тестване с фаззинг, насочено към пълно покритие.
Сега можете да оцените всички възможности за фазирането на тестове във вашите приложения на Java, Rust и Swift и да откриете грешки и уязвимости, които други скенери и методи за тестване могат да пропуснат.
и .
Уведомления на началната страница на средите
(PREMIUM, ULTIMATE, SILVER, GOLD)
Страницата на средите показва общото състояние на вашите среди. В това издание подобрихме тази страница, добавяйки показване на уведомления. Активираните уведомления заедно със състоянието на вашите среди ще ви помогнат да вземете по-бързи мерки за разрешаване на възникнали ситуации.
и .
Вложените конвейери сега могат да задействат своите вложени конвейери
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При използването на вложени конвейери сега е възможно да стартирате нови конвейери в рамките на дъщерни конвейери. Допълнителното ниво на дълбочина може да бъде полезно, ако имате нужда от гъвкавост за генериране на променливо количество конвейери.
По-рано при използването на вложени конвейери на всеки дъщерен конвейер му беше необходима тригер задача, зададена ръчно в родителския конвейер. Сега можете да създавате вложени конвейери, които динамично ще задействат произволен брой нови вложени конвейери. Например, ако имате монорепо, можете динамично да генерирате първия вложен конвейер, който самият ще създава необходимото количество нови конвейери, базирано на промените в клон.
и .
Подобрена навигация между родителските и вложените конвейери
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Навигацията между родителските и вложените конвейери преди беше малко неудобна — изискваше множество кликове, за да стигнете до желания конвейер. Също така беше трудно да се разбере коя точно задача е задействала този конвейер. Сега ще бъде много по-лесно да видите взаимовръзките между родителските и вложените конвейери.
и .
Паралелните матрични задачи показват релевантни променливи в името на задачата
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ако сте използвали , вероятно сте забелязали, че е било трудно да се определи коя матрична променлива е била използвана за определена задача, тъй като имената на задачите изглеждали като matrix 1/4. В релиза 13.4 ще можете да видите релевантни стойности на променливите, които са били използвани в това задание, вместо общото наименование на заданието. Например, ако вашата цел е отстраняване на грешки за архитектура x86, то заданието ще се казва matrix: debug x86.
и .
Други подобрения в GitLab 13.4
Свързване на акаунт в Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Потребителите на GitLab вече ще могат да свързват своите акаунти в GitLab с акаунта в Atlassian Cloud. Това ще позволи да се влезе в GitLab с идентификационните данни на Atlassian, и също така ще постави основите за бъдещи подобрения в интеграцията и с други продукти от линията на Atlassian.
и .
Експорт на списък с всички комити от мержа
(ULTIMATE, GOLD)
На организациите, насочени към спазване на изисквания, им е нужен начин да покажат на одиторите цялостна представа за компонентите, свързани с всяка конкретна промяна в продукцията. В рамките на GitLab това означава, че трябва да съберете на едно място всичко: мърж-реквестове, тикети, конвейери, сканирания за сигурност и друга информация за комита. Досега вие трябваше или ръчно да събирате това в GitLab, или да настройвате инструментите си за събиране на информация, което не беше много ефективно.
Сега можете програмирано да събирате и експортирате тези данни, за да отговорите на изискванията на одита или за провеждане на други анализи. За да експортирате списък с всички комити от мержа за текущата група, трябва да отидете на и да кликнете на бутона Списък с всички комити от мержа. Полученият файл ще съдържа всички комити от мърж-реквеста, техния автор, ID на свързания мърж-реквест, група, проект, потвърдители и друга информация.
и .
Извеждане на списък и управление на лични токени за достъп чрез API
(ULTIMATE, GOLD)
Управлението на достъпа до пространството за имена в GitLab е важна част от дейностите за спазване на изискванията. От принципите на минималните привилегии до деактивиране на достъпа за определен период от време — могат да съществуват различни изисквания, свързани с личните токени за достъп в GitLab. За да улесним поддръжката и управлението на всички тези потребителски данни в рамките на вашето пространство за имена, предоставихме възможност за извеждане на списък с всички лични токени за достъп и опционално чрез API.
Тези подобрения в API на GitLab позволяват на потребителите да извеждат списък и да анулират своите лични токени за достъп, а на администраторите — да извеждат списък и да анулират токените на своите потребители. Сега на администраторите ще им бъде по-лесно да видят кой има достъп до тяхното пространство за имена, да вземат решения относно предоставянето на достъп на база данни за потребителите, а също така да анулират лични токени за достъп, които могат да са компрометирани или които надхвърлят правилата на компанията за управление на достъпа.
и .
Свързаните тикети и други функции сега в GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Преди няколко месеца обявихме план за . Работейки по изпълнението на това обещание, направихме , и (в руската локализация на GitLab „дъска за обсъждане“) с наличност в плана Core. Това се отнася само за връзки от тип „свързан с“, докато връзките от тип „блокира“ и „блокиран“ остават в платените планове.
и .
Показване на името на оригиналния клон в страничната лента на мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При преглед на промените в кода, дискусиите и комитите на мерж-реквеста често е желателно да се направи локален checkout на клона за по-дълбок преглед. Въпреки това, намирането на името на клона става все по-трудно, когато към описанието на мерж-реквеста се добавя все повече съдържание и се налага да се превърта страницата.
Добавихме името на клона в страничната лента на мерж-реквеста, което го прави достъпно по всяко време и спестява необходимостта от превъртане на цялата страница. Както и връзката към мерж-реквеста, разделът с оригиналния клон съдържа удобен бутон „копирай“.
Благодаря за огромен принос в разработката на тази функция!
и .
Указание за наличието на свити файлове в дифовете на мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Мерж-реквестите, които добавят промени в няколко файла, понякога свиват дифовете на големи файлове, за да подобрят производителността на показването. Когато това се случи, може случайно да пропуснете файл по време на преглед, особено в мерж-реквести с много файлове. От версия 13.4 мерж-реквестите ще отбелязват дифовете, съдържащи свити файлове, така че да не пропуснете тези файлове в процеса на кодовия преглед. За още по-голяма яснота планираме да добавим подсветка на тези файлове в бъдещото издание. Следете актуализациите в .
и .
Предупреждение за наличието на свити файлове в дифа на мерж-реквеста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В раздела с дифове на мерж-реквестите големите файлове се свиват за повишаване на производителността. Въпреки това, при прегледа на кода, някои файлове може да бъдат пропуснати, когато прегледчикът преглежда списъка с файлове, тъй като всички големи файлове са свити.
Добавихме видимо предупреждение в горната част на страницата с дифа на мерж-реквеста, за да информираме потребителите, че в този раздел има свит файл. По този начин няма да пропуснете промени в мерж-реквеста по време на прегледа.
и .
Автоматично възстановяване на репозитория на клъстера Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
По-рано, когато основният възел на клъстера Gitaly се изключваше, репозиториите на този възел се маркираха като достъпни само за четене. Това предотвратяваше загуба на данни в ситуации, когато на възела имаше промени, които все още не бяха репликирани. Когато възелът отново се свързваше, GitLab не се възстановяваше автоматично и администраторите трябваше ръчно да стартират процеса на синхронизация или да се примирят със загуба на данни. Също така, другите ситуации, като неуспешно завършване на задачата по репликация на вторичния възел, можеха да доведат до появата на остарели или достъпни само за четене репозитории. В този случай репозиториите оставались остарели, докато не бъде извършена следващата операция по запис, която да стартира задачата по репликация.
За решаване на този проблем Сега планира задача за репликация, когато открие стар репозиторий на една нода и последната версия на репозитория на друга. Тази задача за репликация автоматично актуализира репозитория, което премахва необходимостта от ръчно възстановяване на данни. Автоматичното възстановяване също така осигурява бързо актуализиране на вторичните ноди, ако задачата за репликация завърши неуспешно, вместо да се чака следващата операция за запис. Тъй като много клъстери Gitaly съхраняват голям брой репозитории, това значително намалява времето, което администраторите и инженерите по осигуряване на надеждност прекарват за възстановяване на данни след грешка.
Освен това, автоматичната поправка стартира репликация на репозитории на всяка нова нода Gitaly, добавена към клъстера, което освобождава от ръчната работа при добавяне на нови ноди.
и .
Маркирайте задачата to-do като завършена на страницата за дизайн
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ефективната комуникация в GitLab се основава на списъци със задачи to-do. Ако сте упоменати в коментар, критично е да имате възможността да преминете към задачата и или да започнете да работите по нея, или да я маркирате като вече изпълнена. Също така е важно да имате възможност да назначите задача на себе си, когато трябва да работите нещо или да се върнете към него по-късно.
По-рано не можехте да добавяте задачи или да ги маркирате като завършени, когато работите с дизайни. Това сериозно нарушаваше ефективността на комуникацията между продуктови екипи, тъй като задачите to-do са критично важен елемент от работния процес в GitLab.
В версия 13.4 дизайните наваксват коментарите по тикети в използването на задачи, което прави работата с тях по-последователна и ефективна.
и .
Подобрена документация за отстраняване на проблеми за CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Подобрихме документацията за отстраняване на проблеми за GitLab CI/CD, като добавихме допълнителна информация за разпространени проблеми, с които можете да се сблъскате. Надяваме се, че подобрената документация ще бъде ценен ресурс, който ще ви помогне бързо и лесно да конфигурирате и стартирате GitLab CI/CD.
и .
Мерж-реквестите вече не излизат от опашката за мердж
(PREMIUM, ULTIMATE, SILVER, GOLD)
По-рано мерж-реквестите можеха случайно да излязат от опашката за мердж заради късни коментари. Ако мерж-реквестът вече е бил в опашката и някой добави коментар, който създава ново неизпълнено обсъждане, мерж-реквестът се считаше за неподходящ за мердж и излизаше от опашката. Сега, след като мерж-реквестът е добавен в опашката за мердж, нови коментари могат да се добавят, без да се страхувате, че ще нарушите процеса на мердж.
и .
Показване на стойността на покритие на кода в мерж-реквеста за задания
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Разработчиците трябва да имат възможност да виждат стойността на покритие на кода след приключване на конвейера — дори в сложни сценарии, като работа на конвейера с множество задания, които трябва да бъдат парсвани, за да се изчисли стойността на покритие. По-рано виджетът на мерж-реквеста показваше само средно от тези стойности, което означаваше, че трябваше да посещавате страницата на заданията и обратно към мерж-реквеста, за да получите междинни стойности на покритие. За да спестим вашето време и да ви избавим от тези излишни стъпки, направихме в виджета показване на средната стойност на покритие, нейното изменение между целевата и изходната клонка и изскачащ прозорец, който показва стойността на покритие за всяко задание, на базата на което е изчислено средното значение.
и .
Премахване на пакети от регистъра на пакети при преглед на група
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Регистърът на пакети на GitLab е мястото за съхранение и разпространение на пакети в различни формати. Когато в проекта или групата имате много пакети, трябва бързо да идентифицирате неизползваните пакети и да ги премахнете, за да не бъдат изтегляни от хората. Можете да премахнете пакети от вашия регистър чрез или чрез потребителския интерфейс на регистъра на пакети. Въпреки това, досега не можехте да премахвате пакети при преглед на група през потребителския интерфейс. В резултат на това трябваше да премахвате излишните пакети отделно за всеки проект, което не беше ефективно.
Сега можете да премахвате пакети при преглед на регистъра на пакети на групата. Просто отидете на страницата на регистъра на пакети на групата, филтрирайте пакетите по име и премахвайте всички ненужни.
и .
Мащабиране на пакети Conan до проектно ниво
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Можете да използвате хранилището Conan в GitLab за публикуване и разпространение на зависимости C/C++. В миналото пакети можеха да бъдат мащабирани само до ниво инстанция, тъй като името на пакета Conan можеше да съдържа максимум 51 символ. Ако искате да публикувате пакет от подгрупа, например gitlab-org/ci-cd/package-stage/feature-testing/conan, това беше почти невъзможно.
Сега можете да мащабирате пакети Conan до проектно ниво, което улеснява публикуването и разпространението на зависимостите на вашите проекти.
и .
Поддръжка на нови мениджъри на пакети и езици за сканиране на зависимости
(ULTIMATE, GOLD)
С удоволствие добавяме сканиране на зависимости за проекти с код на C, C++, C# и .Net, които използват NuGet 4.9+ или мениджъри на пакети Conan, към нашия списък . Сега можете да включвате сканиране на зависимости като част от етапа Secure, за да проверявате за известни уязвимости в зависимости, добавени чрез мениджъри на пакети. Намираните уязвимости ще се показват във вашия мерж-реквест заедно с нивото на опасност, за да знаете преди изпълнението на мержа какви рискове носи новата зависимост. Можете също така да конфигурирате проекта си да изисква за зависимости с уязвимости с критично (Critical), високо (High) или неизвестно (Unknown) ниво на опасност.
и .
Уведомления при промяна на настройката на мерж-реквеста на ‘Мержи при успешен завършек на конвейера’
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
По-рано, когато задавахте настройка на мерж-реквеста Мержи, когато конвейера завърши (Merge When Pipeline Succeeds, MWPS) не се изпращаше имейл уведомление. Трябваше да проверявате ръчно статуса или да чакате уведомление за изпълнение на мерж. В тази версия с удоволствие представяме приноса на потребителя , който реши този проблем, добавяйки автоматично изпращане на уведомления на всички, които са абонирани за мерж-реквеста, когато рецензентът променя настройката на мерж на MWPS.
и .
Създаване на EKS клъстери с версия на Kubernetes, зададена от потребителя
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Потребителите на GitLab вече могат сами да избират версия на Kubernetes, която ще бъде предоставена от EKS; можете да избирате между версиите 1.14–1.17.
и .
Създаване на инциденти като типове билети
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Не всяка възникнала проблема веднага задейства изпращането на известия: потребителите докладват за сривове, а членовете на екипите анализират проблеми с производителността. Сега инцидентите са разновидност на билетите, така че вашите екипи ще могат бързо да ги създават в рамките на обичайната работна процедура. Кликнете Нова задача от всяко място в GitLab, и в полето Тип изберете Инцидент.
и .
Споменаване на известия в GitLab в Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ние подобрихме известията в GitLab, добавяйки нов тип споменаване специално за тях в GitLab версия на Markdown, което улеснява споделянето на известия и споменаването на тях. Използвайте ^alert#1234, за да споменете известие в което и да е поле с разметка Markdown: в инциденти, билети или мерж заявки. Това също ще ви помогне да определите задачи, които са създадени от известия, а не от билети или мерж заявки.
и .
Преглед на натоварването на известията по инциденти
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Описание на известието съдържа информация, критично важна за диагностика на сривове и възстановяване, и тази информация трябва да бъде лесно достъпна, за да не се налага да превключвате инструменти или раздели, докато работите по разрешаването на инцидента. Инцидентите, създадени от известия, показват пълното описание на известието в таба Детайли на известието.
С 75% по-бърз разширен търсене
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
GitLab, като единно приложение, има уникалната възможност да направи търсенето на съдържание в целия работен процес на DevOps бързо. В GitLab 13.4 обширното търсене предоставя резултати с 75% по-бързо, когато е , както на GitLab.com.
и .
Преглед на премахнати проекти за администратори
(CORE, STARTER, PREMIUM, ULTIMATE)
Възможността за отлагане на изтриването на проект беше Но преди не беше възможно да видите на едно място всичките проекти, очакващи изтриване. Сега администраторите на потребителските инстанции на GitLab могат да преглеждат всички проекти, очакващи изтриване, на едно място — заедно с бутони за лесно възстановяване на тези проекти.
Тази функция позволява на администраторите да имат по-добър контрол над изтриването на проекти, събирайки цялата необходима информация на едно място и предоставяйки възможност за отмяна на нежеланите действия по изтриване.
Благодаря за тази функция!
и .
Поддръжка на правила за пуш в API за групи
(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD)
По-рано правилата за пуш в групи можеха да се настройват само чрез посещаване на всяка група индивидуално през потребителския интерфейс на GitLab и прилагане на тези правила. Сега можете да управлявате тези правила чрез API, за да поддържате вашите потребителски инструменти и автоматизация в GitLab.
и .
Оттегляне на лични токени за достъп за самоуправляемо хранилище на данни
(ULTIMATE)
предоставя на администраторите информация, необходима за управление на данните на потребителите на техните инстанции на GitLab. Тъй като организациите, ангажирани със съответствието, се различават по строгостта на своите правила за управление на данните, добавихме бутон, който позволява на администраторите, ако желаят, да отзоват токена за личен достъп на потребителя (PAT). Сега администраторите могат лесно да отзоват потенциално компрометирани PAT. Тази функция е полезна за организации, които имат нужда от по-гъвкави опции, за да гарантират спазването на изискванията, с цел минимизиране на смущенията за своите потребители.
и .
Конфигурационен файл за редактора за статични сайтове
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В GitLab 13.4 представяме нов начин за настройка на редактора за статични сайтове. Макар конфигурационният файл да не запазва и не получава никакви параметри в този релийз, ние полагаме основите за бъдеща настройка на поведението на редактора. В следващите релийзи ще добавим в файла .gitlab/static-site-editor.yml параметри за задаване на , на който , пренастройване на синтаксиса на Markdown и други настройки на редактора.
и .
Редактиране на уводната част на файла с помощта на редактора за статични сайтове
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Уводната част (front matter) е гъвкав и удобен начин за определяне на променливи на страницата в файлове с данни, предназначени за обработка от генератора на статични сайтове. Обикновено се използва за задаване на заглавие на страницата, шаблон на макета или автор, но може да се използва и за предаване на всякакъв тип метаданни на генератора при рендериране на страницата в HTML. Включена в самия връх на всеки файл с данни, уводната част обикновено е форматирана като YAML или JSON и изисква последователен и точен синтаксис. Потребителите, незапознати със специфичните правила на синтаксиса, могат неволно да въведат невалиден код, което от своя страна може да предизвика проблеми с форматирането или дори срив на сборката.
Режимът на редактиране WYSIWYG на редактора за статични сайтове вече премахва уводната част от редактора, за да предотврати тези форматиращи грешки. Въпреки това, това не ви позволява да променяте стойностите, съхранявани в тази част, без да се върнете обратно към редактиране в режим на изходен код. В GitLab 13.4 можете да получите достъп до всяко поле и да редактирате стойността му в познат интерфейс, основан на формуляри. Когато натиснете бутона Настройки (Настройки) ще се отвори панел, който показва форма за всяка ключова стойност, определена в началото. Полетата се запълват с текущата стойност и за редактиране на която и да е от тях е достатъчно просто да я въведете в уеб формата. Такова редактиране на уводната част позволява избягване на сложностите в синтаксиса и ви дава пълен контрол върху съдържанието, осигурявайки едновременно унифицирано форматиране на крайния резултат.
и .
GitLab за Jira и DVCS Connector сега в Core
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
За потребителите на Jira в GitLab: и позволяват показването на информация за комити и мърдж реквести от GitLab директно в Jira. В комбинация с нашата вградена интеграция с Jira, можете лесно да преминавате между двете приложения по време на работа.
Тези функции преди бяха достъпни само в нашия план Premium, а сега са достъпни за всички потребители!
и .
Гласуване с мнозинство за транзакции в кластера Gitaly (бета версия)
(CORE, STARTER, PREMIUM, ULTIMATE)
Кластерът Gitaly позволява репликиране на Git хранилища на няколко 'топли' възли Gitaly. Това увеличава отказоустойчивостта, като премахва единични точки на отказ. , представени в GitLab 13.3, предизвикват широковещателно предаване на промените на всички възли Gitaly в кластера, но само възлите Gitaly, които гласуват в съгласие с основния възел, запазват промените на диск. Ако всички реплики не постигнат съгласие, само една копие на промените ще бъде запазено на диск, създавайки единична точка на отказ до завършване на асинхронната репликация.
Гласуването с мнозинство повишава отказоустойчивостта, изисквайки съгласието на мнозинство от възлите (а не на всички) преди запазване на промените на диск. Ако тази переключаема функция е активирана, записът трябва да бъде успешен на няколко възли. Несъгласните възли автоматично се синхронизират чрез асинхронна репликация с тези възли, които образуват кворум.
и .
Поддръжка на потребителска схема за валидация на JSON в Web IDE
(PREMIUM, ULTIMATE, SILVER, GOLD)
Проектите, в които хората пишат конфигурации в JSON или YAML формат, често са подложени на проблеми, защото е лесно да направите печатна грешка и нещо да се счупи. Можете да напишете инструменти за проверка, които да улавят тези проблеми в CI конвейера, но използването на файл с JSON схема може да бъде полезно, за да предостави документация и подсказки.
Участниците в проекта могат да определят в техния репозитори пътя към потребителската схема в файла .gitlab/.gitlab-webide.yml, който посочва схемата и пътя към файловете за валидация. При зареждане на определен файл в Web IDE ще бъде налична допълнителна обратна връзка и проверка, които ще помогнат за създаването на файла.
и .
Максималният брой клонове на насочен ацикличен граф (DAG) е увеличен до 50
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ако използвате конвейери (Directed Acyclic Graph (DAG)), може да сте открили, че ограничението от 10 задачи, които задача може да посочи в needs:, твърде строго. В 13.4 по подразбиране лимитът беше увеличен от 10 на 50, за да се осигурят по-сложни мрежи от връзки между задачите в вашите конвейри.
Ако сте администратор на потребителски инстанс на GitLab, можете да повишите този лимит още повече, настройвайки превключваща функция, въпреки че не предлагаме официална поддръжка за това.
и .
Подобрено поведение needs за пропуснати задачи
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
В някои случаи пропусната задача в конвейра можеше да се счита за успешна по отношение на зависимостите, посочени в needs, поради което се стартираха последващи задачи, което не трябваше да се случва. Това поведение е коригирано в версия 13.4 и needs сега коректно обработва случаите на пропуснати задачи.
и .
Забранете последния артефакт на задачата, за да предотвратите неговото изтриване
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
GitLab вече автоматично блокира последния артефакт на успешна задача и конвейр на всяка активна клонка, сливане на заявки или таг, за да предотврати неговото изтриване след изтичането на срока. Става по-лесно да се установят по-агресивни правила за изтичане за почистване на стари артефакти. Това помага за намаляване на консумацията на дисково пространство и гарантира, че винаги ще имате копие на последния артефакт от конвейра.
и .
Ръководство за CI/CD за оптимизиране на конвейра
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Оптимизацията на работата на CI/CD конвейра може да увеличи скоростта на доставка и да спести разходи. Подобрихме нашата документация, добавяйки кратко ръководство за постигане на максимални резултати от оптимизацията на вашите конвейри.
и .
Докладът за тестване е сортиран по статус на теста
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
— това е прост начин да видите резултатите от всички тестове в конвейера. Въпреки това, при голямо количество тестове, търсенето на неуспешни тестове може да отнеме много време. Други проблеми, които могат да затруднят използването на отчета, включват трудности при превъртането на дългите изходни данни на трасировката и закръгляването на времето до нула за тестове, изпълнявани за по-малко от 1 секунда. Сега, по подразбиране, отчетът за тестването при сортиране поставя неуспешните тестове в началото на отчета, след което сортира тестовете по продължителност. Това опростява намирането на неуспехи и дълги тестове. Освен това, продължителността на тестовете сега се показва в милисекунди или секунди, което прави четенето им много по-бързо, а също така бяха решени предишните проблеми с превъртането.
и .
Ограничения за размер на файловете, които могат да бъдат качвани в регистъра на пакети
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Сега има ограничения за размерите на файловете на пакетите, които могат да бъдат качвани в регистъра на пакети на GitLab. Ограниченията бяха добавени за оптимизация на производителността на регистъра на пакети и за предотвратяване на злоупотреби. Ограниченията зависят от формата на пакета. За GitLab.com максималните размери на файловете са:
- Conan: 250MB
- Maven: 3GB
- NPM: 300MB
- NuGet: 250MB
- PyPI: 3GB
За потребителските инстанции на GitLab стойностите по подразбиране са същите. Въпреки това, администраторът може да актуализира ограниченията с помощта на .
и .
Използвайте CI_JOB_TOKEN за публикуване на пакети PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Можете да използвате GitLab PyPI хранилище за създаване, публикуване и споделяне на Python пакети заедно с изходния код и CI/CD конвейерите. Въпреки това, преди не можехте да се удостоверите в хранилището с предварително зададена променлива на средата CI_JOB_TOKEN. В резултат на това, вие трябваше да използвате вашите лични удостоверителни данни за актуализиране на Python хранилището, или може би сте решили въобще да не използвате хранилището.
Сега е по-лесно да използвате GitLab CI/CD за публикуване и инсталиране на пакети PyPI с помощта на предварително зададена променлива на средата CI_JOB_TOKEN.
и .
Профили на скенера DAST по заявка
(ULTIMATE, GOLD)
К сканирането DAST по заявка, което беше , добавени са профили на DAST скенера. Те разширяват възможностите за конфигуриране на това сканиране, позволявайки бързо създаване на няколко профила, за да обхванат различни видове сканирания. В 13.4 профилът на скенера първоначално включва параметър за таймаут на скенера, който определя колко дълго трябва да работи DAST скенерът, когато се опитва да открие всички страници на сканирания сайт. Профилът също така включва параметър за таймаут на целевия сайт, за да зададе колко дълго скенерът трябва да чака, докато сайтът стане достъпен, преди да прекрати сканирането, ако сайтът не отговаря с код на статус 200 или 300. С течение на времето, ние ще продължим да подобряваме тази функция в следващите версии, като ще бъдат добавени допълнителни конфигурационни параметри в профила на скенера.
и .
Прост файл за конфигурация на пренасочвания за GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Ако използвате GitLab Pages и искате по-добре да управлявате промените в URL адресите, може да сте заб注意ли, че управлението на пренасочвания на вашия сайт GitLab Pages е било невъзможно. Сега GitLab ви позволява да настроите правила за пренасочване от един URL адрес на друг за вашия сайт Pages, добавяйки файл за конфигурация в репозитория. Тази функция стана възможна благодарение на участието на Kevin Barnett (), нашия Eric Eastwood () и екипа на GitLab. Благодаря на всички за приноса.
и .
Състояние на Terraform, управлявано от GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Достъпът до предишни версии на състоянието на Terraform е необходим както за спазване на изискванията, така и за отстраняване на проблеми при необходимост. Поддръжката на управление на версии на Terraform, управляван от GitLab, е налична от GitLab 13.4. Управлението на версиите се включва автоматично за новите файлове на Terraform. Съществуващите файлове на Terraform ще бъдат в по-късен релиз.
и .
Важни детайли за известията за инциденти
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
При обработка на инциденти, е нужно лесно да определите колко дълго предупреждението е било отворено и колко пъти е възникнало събитие. Тези детайли често са от решаващо значение при определяне на влиянието върху клиента и какво трябва да направи вашият екип първо. На новата панел за подробности за инциденти показваме времето на започване на предупреждението, броя на събитията и връзка към оригиналното предупреждение. Тази информация е достъпна за инциденти, които са създадени от предупреждения.
и .
Настройка и редактиране на параметъра за сериозност на инцидента
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
Параметърът „сериозност на инцидента“ позволява на специалистите по реакция и заинтересованите страни да определят последиците от прекъсване на работата, както и методите и спешността на реакцията. Докато вашият екип споделя резултатите по време на разрешаване на инцидента и възстановявайки работоспособността, те могат да променят този параметър. Сега можете да редактирате сериозността на инцидента на дясната странична лента на страницата „Сведения за инцидента“, а степента на сериозност се показва в списъка с инциденти.
и .
Създаване, редактиране и изтриване на правила за мрежова сигурност на контейнери
(ULTIMATE, GOLD)
Това подобрение на редактора за правила за мрежова сигурност на контейнери позволява на потребителите лесно да създават, редактират и изтриват своите правила директно от потребителския интерфейс на GitLab. Възможностите на редактора включват режим .yaml за опитни потребители и редактор на правила с интуитивен интерфейс за тези, които не са запознати със мрежовите правила. Можете да намерите нови възможности за управление на правилата в раздел Сигурност и съответствие > Управление на заплахи > Политики (Security & Compliance > Threat Management > Policies).
и .
Поддръжка на Azure за хранилище на blob-обекти
(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD)
И GitLab, и GitLab Runner вече поддържат , което опростява стартирането на услугите на GitLab в Azure.
Инстанси на GitLab поддържат Azure за всички типове хранилища на обекти, включително LFS файлове, CI артефакти и . За да настроите хранилище на blob-обекти Azure, следвайте инструкциите за инсталация или .
Обработчици на задачи на GitLab също поддържат Azure за съхранение на . Azure съхранението може да бъде конфигурирано чрез раздела .
и .
Omnibus ARM64 пакети за Ubuntu и OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
В отговор на нарастващото търсене за поддръжка на GitLab за 64-битова архитектура ARM, с радост обявяваме наличността на официалния ARM64 Ubuntu 20.04 Omnibus пакет. Огромни благодарности на Zitai Chen и Guillaume Gardet за значителния принос, който направиха — техните мердж реквести изиграха ключова роля!
За да изтеглите и инсталирате пакета за Ubuntu 20.04, посетете нашата и изберете Ubuntu.
и .
Поддръжка на удостоверяване с помощта на смарт карти за GitLab Helm chart
(PREMIUM, ULTIMATE)
Смарт картите, като Common Access Cards (CAC), вече могат да се използват за удостоверяване в инстанцията на GitLab, инсталирана чрез Helm chart. Смарт картите се удостоверяват в локалната база данни с помощта на X.509 сертификати. С това поддръжката на смарт карти с Helm chart вече е в съответствие с поддръжката на смарт карти, налична в Omnibus раз deployments.
и .
Подробни release notes и инструкции за обновление/инсталиране можете да прочетете в оригиналния англоезичен пост: .
Преводът от английски беше извършен от , , и .
Източник: habr.com
