Вышел релиз 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 с управляемым GitLab состоянием Terraform для поддержки соответствия требованиям и удобности в отладке. И наконец, панель управления безопасностью в инстансе превратилась в центр безопасности GitLab с отчётами об уязвимостях и настройками безопасности.

Более удобная и эффективная работа с GitLab

Мы улучшили наш глобальный поиск, добавив в него быструю навигацию из поисковой строки, позволяющую легко переходить к последним тикетам, группам, проектам, настройкам и разделам справки. Мы рады объявить, что в GitLab Pages появились редиректы для переадресации отдельных страниц и каталогов внутри сайта, что позволит пользователям более эффективно разворачивать свои сайты. А тем, кто хотел бы получать расширенную информацию о развёртывании, этот релиз позволяет управлять сотнями поддерживаемых развёртываний проектов с панели инструментов окружения! 🎉

Вклады с открытым исходным кодом

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

И это ещё только начало!

Как и всегда, в общем обзоре слишком мало места, а классных фич в релизе 13.4 очень много. Вот ещё несколько:

Если вы хотите заранее узнать, что вас ждёт в следующем релизе, посмотрите наше видео по релизу 13.5.

Посмотрите наш вебкаст “Resiliency In Challenging Times”.

GitLab MVP badge

MVP этого месяца — Fabio Huser

Fabio внёс значительный вклад в отображение покрытия кода в диффах мерж-реквестов — фичу, которую очень долго ждали в сообществе GitLab. Это действительно важный вклад с нетривиальными изменениями, которые требовали постоянного сотрудничества с членами команды GitLab и затрагивали множество областей проекта, таких как UX, фронтенд и бэкенд.

Основные фичи релиза GitLab 13.4

Используйте ключи HashiCorp Vault в заданиях CI

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

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

Use HashiCorp Vault secrets in CI jobs

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

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

(PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure

Интеграция GitLab с Kubernetes уже давно позволяет развёртывать на кластерах Kubernetes без необходимости ручной настройки. Многим пользователям понравилась простота использования этой связки, в то время как другие столкнулись с некоторыми трудностями. Для текущей интеграции ваш кластер должен быть доступен из интернета, чтобы GitLab мог иметь к нему доступ. Для многих организаций это не представляется возможным, поскольку они ограничивают доступ к кластерам из соображений безопасности, соответствия требованиям или в целях регулирования. Чтобы обойти эти ограничения, пользователям нужно было создавать свои инструменты поверх GitLab, иначе они не смогли бы использовать эту возможность.

Сегодня мы представляем GitLab Kubernetes Agent — новый способ развёртывания на кластерах Kubernetes. Агент работает внутри вашего кластера, так что вам не потребуется открывать его для всего интернета. Агент координирует развёртывание, запрашивая новые изменения у GitLab, вместо того, чтобы GitLab отправлял обновления на кластер. Независимо от того, какой метод GitOps вы используете, GitLab вам подойдёт.

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

Introducing the GitLab Kubernetes Agent

Документация по GitLab Kubernetes Agent и оригинальный тикет.

Предоставляйте пользователям разрешения на развёртывание без доступа к коду

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

Ранее система разрешений в GitLab не давала возможности грамотно разделить обязанности в вашей команде между теми, кто отвечает за разработку, и теми, кто отвечает за развёртывание. С релизом GitLab 13.4 вы можете дать разрешение на подтверждение мерж-реквестов для развёртывания, а также на фактическое развёртывание кода людям, не пишущим код, при этом не предоставляя им права доступа мейнтейнера (в русской локализации GitLab «сопровождающий»).

Grant users deployment permissions without code access

Документация по доступу к окружению и оригинальный эпик.

Центр безопасности

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Ранее управление уязвимостями на уровне инстанса было ограничено как по функциональности, так и по гибкости. Интерфейс представлял собой одну страницу, которая объединяет в себе детали уязвимостей, графики метрик и настройки. Не так уж много места для развития этих функций или использования других средств безопасности.

Мы внесли фундаментальные изменения в управление безопасностью и её прозрачностью в GitLab. Панель безопасности инстанса преобразовалась в целый центр безопасности. Самое большое изменение — это введение новой структуры меню: вместо одной страницы теперь вы отдельно видите панель управления безопасностью, отчёт об уязвимостях и раздел настроек. Хотя функциональность не изменилась, разбиение на части позволит улучшать этот раздел, что в противном случае было бы затруднительно. Это также создаёт базу для добавления в будущем других возможностей, связанных с безопасностью.

У специального раздела для отчёта об уязвимостях теперь больше места для отображения важных деталей. Здесь собраны уязвимости, которые в настоящее время находятся в списке уязвимостей проекта. Перенос виджетов с метриками уязвимостей в отдельный раздел создаёт удобную панель управления безопасностью. Теперь это холст для будущих визуализаций — не только для управления уязвимостями, но и для любых метрик, связанных с безопасностью. Наконец, отдельная область настроек создаёт общее пространство для всех настроек безопасности на уровне инстанса, не только для управления уязвимостями.

Security Center

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

Переключаемые фичи теперь в GitLab Starter

(STARTER, PREMIUM, ULTIMATE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release

В 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!

Quick navigation using the Search bar

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

Отображение покрытия кода в диффах мерж-реквестов

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

При ревью мерж-реквеста может быть трудно определить, покрыт ли изменённый код юнит-тестами. Вместо этого проверяющие могут полагаться на общее покрытие и требовать его увеличить, прежде чем подтверждать мерж-реквест. Это может привести к бессистемному подходу к написанию тестов, что на самом деле не улучшит качество кода или его покрытие тестами.

Теперь при просмотре диффа мерж-реквеста вы увидите наглядное отображение покрытия кода. Новые пометки позволят быстро понять, покрыт ли изменённый код юнит-тестом, что поможет ускорить ревью кода и время мержа и развёртывания нового кода.

Спасибо Fabio Huser и Siemens за эту фичу!

Inline code coverage remarks inside MR diffs

Документация по отображению покрытия кода тестами и оригинальный тикет.

Больше окружений и проектов на панели окружений

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

С релиза GitLab 12.5 с помощью панели окружений вы могли отслеживать состояние окружений, но не более семи окружений в трёх проектах. Мы улучшили эту панель в релизе 13.4, разбив её на страницы, чтобы помочь вам поддерживать ваши окружения и управлять ими в больших масштабах. Теперь вы можете видеть больше окружений в большем количестве проектов.

Track environments at scale with the Environments Dashboard

Документация по панели окружений и оригинальный тикет.

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure

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

Taking ownership of the GitLab Terraform provider

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

Фаззинг-тестирование API со спецификациями OpenAPI или HAR-файлом

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Фаззинг-тестирование 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, за ней последует возможность построить график среднего покрытия с течением времени.

Code Coverage Data for all projects in a group

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

Поддержка новых языков для полного фаззинг-тестирования

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Этот релиз представляет поддержку нескольких новых языков для фаззинг-тестирования, нацеленного на полное покрытие.

Теперь вы можете оценить все возможности фаззинг-тестирования в ваших приложениях на Java, Rust и Swift и найти ошибки и уязвимости, которые другие сканеры и методы тестирования могут пропустить.

New language support for coverage-guided fuzz testing

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

Оповещения на главной странице окружений

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Release

Страница окружений показывает общее состояние ваших окружений. В этом релизе мы улучшили эту страницу, добавив отображение оповещений. Сработавшие оповещения вместе со статусом ваших окружений помогут вам быстрее принимать меры по исправлению возникающих ситуаций.

Show alerts in the environment index page

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

Вложенные конвейеры теперь могут запускать свои вложенные конвейеры

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

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

Ранее при использовании вложенных конвейеров каждому дочернему конвейеру требовалось задание-триггер, вручную заданное в родительском конвейере. Теперь же вы можете создавать вложенные конвейеры, которые будут динамически запускать любое количество новых вложенных конвейеров. Например, если у вас монорепозиторий, вы можете динамически генерировать первый вложенный конвейер, который сам будет создавать необходимое количество новых конвейеров, основываясь на изменениях в ветке.

Child pipelines can now trigger their own child pipelines

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

Улучшенная навигация между родительскими и вложенными конвейерами

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

Перемещаться между родительскими и вложенными конвейерами ранее было не очень удобно — нужно было множество кликов, чтобы добраться до нужного конвейера. Также было нелегко понять, какое именно задание запустило этот конвейер. Теперь увидеть связи между родительскими и вложенными конвейерами станет гораздо проще.

Improved navigation between parent and child pipelines

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

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

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

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

Parallel matrix jobs show relevant variables in job name

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

Другие улучшения в GitLab 13.4

Подключение аккаунта Atlassian

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage

Пользователи GitLab теперь смогут подключать свои аккаунты GitLab к аккаунту Atlassian Cloud. Это позволит авторизоваться в GitLab с учётными данными Atlassian, а также заложит основу для будущих улучшений в интеграции Gitlab с Jira и с другими продуктами из линейки Atlassian.

Connect an Atlassian Account

Документация по интеграции с Atlassian и оригинальный тикет.

Экспорт списка всех коммитов мержа

(ULTIMATE, GOLD) Стадия цикла DevOps: Manage

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

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

Export a list of all merge commits

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

Вывод списка и управление личными токенами доступа через API

(ULTIMATE, GOLD) Стадия цикла DevOps: Manage

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

Эти улучшения в API GitLab позволяют пользователям выводить список и аннулировать свои собственные личные токены доступа, а администраторам — выводить список и аннулировать токены своих пользователей. Теперь администраторам будет легче видеть тех, у кого есть доступ к их пространству имён, принимать решения о предоставлении доступа на основе данных пользователей, а также аннулировать личные токены доступа, которые могли быть скомпрометированы или которые выходят за пределы правил компании по управлению доступом.

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

Связанные тикеты и другие фичи теперь в GitLab Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Plan

Несколько месяцев назад мы объявили план по переводу 18 фич в открытый исходный код. Работая над выполнением этого обещания, мы сделали связанные тикеты, экспорт тикетов в CSV и режим фокуса на доске задач (в русской локализации GitLab «доска обсуждений») доступными в плане Core. Это относится только к отношениям типа “связан с”, отношения типа “блокирует” и “блокируется” остаются в платных планах.

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

Отображение имени исходной ветки на боковой панели мерж-реквеста

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

При ревью изменений кода, обсуждений и коммитов мерж-реквеста зачастую желательно делать локальный checkout ветки для более глубокого ревью. Однако найти имя ветки становится всё сложнее по мере того, как к описанию мерж-реквеста добавляется больше контента, и приходится всё дальше листать страницу.

Мы добавили имя ветки на боковую панель мерж-реквеста, что делает его доступным в любое время и избавляет от необходимости пролистывать всю страницу. Как и ссылка на мерж-реквест, раздел с исходной веткой содержит удобную кнопку «скопировать».

Спасибо Ethan Reesor за огромный вклад в разработку этой фичи!

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

Мерж-реквесты, которые добавляют изменения к нескольким файлам, иногда сворачивают диффы больших файлов, чтобы улучшить производительность отображения. Когда это происходит, можно случайно пропустить файл при ревью, особенно в мерж-реквестах с большим числом файлов. Начиная с версии 13.4 мерж-реквесты будут отмечать диффы, содержащие свёрнутые файлы, благодаря чему вы не пропустите эти файлы в процессе ревью кода. Для ещё большей ясности мы планируем добавить подсветку этих файлов в будущем релизе. Следите за обновлениями в тикете gitlab#16047.

Emphasize collapsed diffs in merge request diffs

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

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

Мы добавили видимое предупреждение наверху страницы диффа мерж-реквеста, чтобы информировать пользователей о том, что в этом разделе есть свёрнутый файл. Таким образом, вы не пропустите никакие изменения в мерж-реквесте при ревью.

Warning on merge request diff when files are collapsed

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

Раньше, когда первичная нода кластера Gitaly отключалась, репозитории на этой ноде помечались как доступные только для чтения. Это предотвращало потерю данных в ситуациях, если на ноде были изменения, которые ещё не реплицировались. Когда нода снова подключалась, GitLab не восстанавливался автоматически, и администраторам приходилось вручную запускать процесс синхронизации или мириться с потерей данных. Также могли приводить к появлению устаревших или доступных только для чтения репозиториев и другие ситуации, такие как неудачное завершение задания по репликации на вторичной ноде. В этом случае репозиторий оставался устаревшим до тех пор, пока не была произведена следующая операция записи, которая бы запустила задание по репликации.

Для решения этой проблемы Praefect теперь планирует задание по репликации, когда он обнаруживает устаревший репозиторий на одной ноде и последнюю версию репозитория на другой. Это задание по репликации делает репозиторий актуальным автоматически, что избавляет от необходимости восстанавливать данные вручную. Автоматическое восстановление также обеспечивает быстрое приведение к актуальному состоянию вторичных нод, если задание по репликации завершается неудачно, вместо того, чтобы ждать следующей операции записи. Так как многие кластеры Gilaly хранят большое число репозиториев, это значительно снижает время, которое администраторы и инженеры по обеспечению надёжности тратят на восстановление данных после ошибки.

Кроме того, автоматическая починка запускает репликацию репозиториев на любой новой ноде Gitaly, добавленной к кластеру, что избавляет от ручной работы при добавлении новых нод.

Документация по восстановлению данных Gitaly и оригинальный тикет.

Отмечайте задание to-do как выполненное на странице дизайна

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

Эффективная коммуникация в GitLab основана на списках заданий to-do. Если вас упомянули в комментарии, то критически важно иметь возможность перейти к заданию и либо начать что-то делать, либо пометить его как уже выполненное. Также важно иметь возможность назначать задание себе, когда вам нужно поработать над чем-то или вернуться к этому позже.

Ранее вы не могли добавлять задания или помечать их как выполненные при работе с дизайнами. Это серьёзно нарушало эффективность коммуникации между продуктовыми командами, так как задания to-do — это критически важный элемент рабочего процесса в GitLab.

В релизе 13.4 дизайны догоняют комментарии к тикетам в использовании заданий, что делает работу с ними более последовательной и эффективной.

Mark a to-do as Done in the Design View

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

Улучшенное руководство по устранению неполадок для 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

У разработчиков должна быть возможность видеть значение покрытия кода после завершения конвейера — даже в сложных сценариях, таких как работа конвейера с несколькими заданиями, которые нужно парсить, чтобы рассчитать значение покрытия. Ранее виджет мерж-реквеста показывал только среднее от этих значений, что означало, что вам приходилось переходить на страницу задания и обратно к мерж-реквесту, чтобы получить промежуточные значения покрытия. Чтобы сэкономить ваше время и избавить вас от этих лишних шагов, мы сделали в виджете отображение среднего значения покрытия, его изменения между целевой и исходной ветками и всплывающую подсказку, которая показывает значение покрытия для каждого задания, на основе которого было рассчитано среднее значение.

Show job data for Code Coverage value in MR

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

Удаление пакетов из реестра пакетов при просмотре группы

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package

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

Теперь вы можете удалять пакеты при просмотре реестра пакетов группы. Просто перейдите на страницу реестра пакетов группы, отфильтруйте пакеты по имени и удалите все ненужные.

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

Масштабирование пакетов Conan до уровня проекта

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package

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

Теперь вы можете масштабировать пакеты Conan до уровня проекта, что позволяет легко публиковать и распространять зависимости ваших проектов.

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

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

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

Мы рады добавить сканирования зависимостей для проектов с кодом на C, C++, C# и .Net, которые используют NuGet 4.9+ или менеджеры пакетов Conan, к нашему списку поддерживаемых языков и фреймворков. Теперь вы можете включать сканирование зависимостей как часть стадии Secure, чтобы проверять на известные уязвимости зависимости, добавленные через менеджеры пакетов. Найденные уязвимости будут отображаться в вашем мерж-реквесте вместе с уровнем их опасности, чтобы вы знали до выполнения мержа какие риски несёт в себе новая зависимость. Вы также можете настроить свой проект так, чтобы он требовал подтверждения мерж-реквеста для зависимостей с уязвимостями с критическим (Critical), высоким (High) или неизвестным (Unknown) уровнем опасности.

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

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release

Ранее при задании настройки мерж-реквеста Мержить, когда завершится конвейер (Merge When Pipeline Succeeds, MWPS) никакого email-уведомления не отправлялось. Вам приходилось вручную проверять статус или ждать уведомления о выполнении мержа. В этом релизе мы рады представить вклад пользователя @ravishankar2kool, который решил эту проблему, добавив автоматическую отправку уведомлений всем, кто подписан на мерж-реквест, когда ревьюер меняет настройку мержа на MWPS.

Notifications when 'Merge When Pipeline Succeeds' is set on a merge request

Документация по уведомлениям о событиях мерж-реквестов и оригинальный тикет.

Создание кластеров EKS с версией Kubernetes, заданной пользователем

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Configure

Пользователи GitLab теперь могут сами выбирать версию Kubernetes, которая будет предоставлена EKS; вы можете выбирать между версиями 1.14–1.17.

Документация по добавлению кластеров EKS и оригинальный тикет.

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

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

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

Create incidents as a type of issue

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

Упоминание оповещений 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

Описание оповещения содержит информацию, критически важную для диагностирования сбоев и восстановления, и эта информация должна быть легко доступной, чтобы вам не приходилось переключать инструменты или вкладки при работе над разрешением инцидента. Инциденты, созданные из оповещений, отображают полное описание оповещения во вкладке Alert Details.

View alert payload on incidents

На 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. Эта фича полезна для организаций, которым нужны более гибкие варианты для обеспечения исполнения требований, чтобы свести к минимуму отвлечения своих пользователей.

Revoke PATs for self-managed credential inventory

Документация по хранилищу учётных данных и оригинальный тикет.

Файл конфигурации для редактора статических сайтов

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

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

Документация по настройке редактора статических сайтов и оригинальный эпик.

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

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

Вступительная часть (front matter) — это гибкий и удобный способ определения переменных страницы в файлах данных, предназначенных для обработки генератором статических сайтов. Обычно она используется для установки заголовка страницы, шаблона макета или автора, но может использоваться для передачи любого типа метаданных в генератор при рендере страницы в HTML. Включаемая в самый верх каждого файла данных, вступительная часть обычно форматируется как YAML или JSON и требует согласованного и точного синтаксиса. Пользователи, незнакомые с конкретными правилами синтаксиса, могут непреднамеренно ввести недопустимую разметку, что, в свою очередь, может вызвать проблемы с форматированием или даже сбои сборки.

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

Edit front matter using the Static Site Editor

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

GitLab для Jira и DVCS Connector теперь в Core

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Create

Для пользователей Jira в GitLab: приложение GitLab для Jira и DVCS Connector позволяют отображать информацию о коммитах и мерж-реквестах GitLab непосредственно в Jira. В сочетании с нашей встроенной интеграцией с Jira вы можете легко перемещаться между двумя приложениями во время работы.

Эти функции раньше были доступны только в нашем плане Premium, а теперь они доступны всем пользователям! 🎉

Документация по интеграции с Jira и оригинальный тикет.

Голосование с большинством голосов для транзакций кластера Gitaly (бета-версия)

(CORE, STARTER, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create

Кластер Gitaly позволяет реплицировать репозитории Git на несколько «тёплых» нод Gitaly. Это повышает отказоустойчивость за счёт устранения единичных точек отказа. Транзакционные операции, представленные в GitLab 13.3, вызывают широковещательную передачу изменений на все ноды Gitaly в кластере, но только ноды Gitaly, которые голосуют по согласованию с первичной нодой, сохраняют изменения на диск. Если все ноды-реплики не пришли к согласию, только одна копия изменения будет сохранена на диске, создавая единую точку отказа до завершения асинхронной репликации.

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

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

Поддержка пользовательской схемы для валидации JSON в Web IDE

(PREMIUM, ULTIMATE, SILVER, GOLD) Стадия цикла DevOps: Create

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

Участники проекта могут определить в их репозитории путь к пользовательской схеме в файле .gitlab/.gitlab-webide.yml, который указывает схему и путь к файлам для проверки. При загрузке определённого файла в Web IDE будет видна дополнительная обратная связь и проверка, которые помогут создать файл.

Support custom JSON schema validation in the 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: Package

Теперь есть ограничения на размер файлов пакетов, которые можно загружать в реестр пакетов GitLab. Ограничения были добавлены для оптимизации производительности реестра пакетов и предотвращения злоупотреблений. Ограничения зависят от формата пакета. Для GitLab.com максимальные размеры файлов:

Для пользовательских инстансов GitLab значения по умолчанию такие же. Однако администратор может обновить ограничения с помощью консоли Rails.

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

Используйте CI_JOB_TOKEN для публикации пакетов PyPI

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Package

Вы можете использовать репозиторий GitLab PyPI для создания, публикации и совместного использования пакетов Python вместе с исходным кодом и конвейерами CI/CD. Однако раньше вы не могли пройти аутентификацию в репозитории с помощью предварительно определённой переменной окружения CI_JOB_TOKEN. В результате вам приходилось использовать свои личные учётные данные для обновления репозитория PyPI, или вы, возможно, решали вообще не использовать репозиторий.

Теперь стало проще использовать GitLab CI/CD для публикации и установки пакетов PyPI с помощью предопределённой переменной окружения CI_JOB_TOKEN.

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

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

(ULTIMATE, GOLD) Стадия цикла DevOps: Secure

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

On-demand DAST Scanner Profiles

Документация по профилю сканера DAST и оригинальный тикет.

Простой файл конфигурации редиректов для GitLab Pages

(CORE, STARTER, PREMIUM, ULTIMATE, FREE, BRONZE, SILVER, GOLD) Стадия цикла DevOps: Release

Если вы используете 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: Configure

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

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

Важные детали оповещения об инцидентах

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

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

Highlight critical alert details on incidents

Документация по управлению инцидентами и оригинальный эпик.

Установка и редактирование параметра серьёзности инцидента

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

Параметр «серьёзность инцидента» позволяет специалистам по реагированию и заинтересованным сторонам определять последствия перебоя в работе, а также методы и срочность реагирования. По мере того как ваша команда делится результатами во время устранения инцидента и восстанавливает работоспособность, они могут изменять этот параметр. Теперь вы можете редактировать серьёзность инцидента на правой боковой панели страницы «Сведения об инциденте», а степень серьёзности отображается в списке инцидентов.

Set and edit incident severity

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

Создание, редактирование и удаление правил сетевой безопасности контейнеров

(ULTIMATE, GOLD) Стадия цикла DevOps: Defend

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

Create, Edit, and Delete for Container Network Policies

Документация по редактору сетевых правил и оригинальный эпик.

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

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

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

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

Обработчики заданий GitLab также поддерживают Azure для хранения распределённого кэша. Хранилище Azure можно настроить с помощью раздела [runners.cache.azure].

Документация по использованию хранилища BLOB-объектов 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.

Документация по пакетам для ARM64 и оригинальный тикет.

Поддержка аутентификации с помощью смарт-карт для GitLab Helm chart

(PREMIUM, ULTIMATE) Доступность

Смарт-карты, например карты общего доступа (CAC), теперь можно использовать для аутентификации в инстансе GitLab, развёрнутом через Helm chart. Смарт-карты аутентифицируются в локальной базе данных с помощью сертификатов X.509. Благодаря этому поддержка смарт-карт с Helm chart теперь находится в соответствии с поддержкой смарт-карт, доступной в развёртываниях Omnibus.

Документация по настройкам аутентификации с помощью смарт-карт и оригинальный тикет.


Подробные release notes и инструкции по обновлению/установке можно прочитать в оригинальном англоязычном посте: GitLab 13.4 released with Vault for CI variables and Kubernetes Agent.

Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.