Вышел релиз GitLab 14.1 с реестром Helm Chart и правилами эскалации
Мы рады представить вам релиз GitLab 14.1 с возможностью собирать, публиковать и распространять Helm-чарты, создавать правила эскалации для ответственных за страницу, подключать обработчики заданий GitLab к вашим кластерам Kubernetes, обеспечивать соблюдение решений по покрытию кода и многим другим!
Это — лишь несколько основных из более чем 50 улучшений в этом релизе. Читайте далее, и вы узнаете всё об этих новых фичах. Чтобы узнать, что будет в следующем месяце, зайдите на страницу предстоящих релизов, там вы найдёте видео по будущему релизу 14.2.
MVP этого месяца — Andrew Smith
Andrew принимал активное участие во многих мерж-реквестах в релизе 14.1, помогая улучшить планирование в GitLab. Он внёс значительные улучшения в наши доски задач (в русской локализации GitLab «доски обсуждений») и эпиков (в русской локализации GitLab «цели»). Благодаря его работе пользователи GitLab теперь могут сортировать эпики в списке по названию, просматривать количество открытых тикетов и их суммарный вес и отслеживать прогресс выполнения на досках эпиков, а также просматривать веса в списках майлстоунов (в русской локализации GitLab «этапы»).
Помимо значительного вклада в разработку продукта, Andrew также тесно сотрудничал с нашей командой, помогая выявлять и устранять ошибки и препятствия, которые встречались на его пути.
Спасибо Andrew за то, что он помогает сделать GitLab лучше! 🙌
Основные фичи релиза GitLab 14.1
Собирайте, публикуйте и распространяйте Helm-чарты в GitLab
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Helm определяет chart (далее — чарт) как пакет Helm, содержащий все определения ресурсов, необходимых для запуска приложения, инструмента или сервиса в кластере Kubernetes. Для организаций, которые создают собственные Helm-чарты и управляют ими, нужен централизованный репозиторий для их хранения и распространения.
GitLab уже поддерживает множество форматов пакетных менеджеров, почему бы не поддерживать и Helm? Этот вопрос несколько месяцев назад задал участник нашего сообщества и MVP релиза 14.0 Mathieu Parent, перед тем как приступить к работе над новым реестром GitLab Helm chart. Сотрудничество между сообществом и GitLab является частью нашей стратегии двойного маховика и одной из причин, по которым работа в GitLab приносит нам удовольствие. Браво, Mathieu!
Теперь вы можете использовать свой проект GitLab для публикации и распространения упакованных чартов Helm. Просто добавьте свой проект в качестве удалённого ресурса, авторизовавшись с помощью персонального токена доступа, развёртывания или задания CI/CD. После этого вы можете использовать клиент Helm или GitLab CI/CD для управления Helm-чартами. Вы также можете загрузить их с помощью API или через пользовательский интерфейс.
Что будет дальше? Сначала мы хотели бы предоставить дополнительные метаданные для чартов. Затем мы начнём сами использовать эту фичу в GitLab, заменив ею текущий https://charts.gitlab.io/.
Так что попробуйте эту фичу и дайте нам знать, что вы думаете, оставив комментарий в эпике GitLab-6366.
Документация по репозиторию Helm-чартов в GitLab и оригинальный тикет.
Правила эскалации
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor
Быть дежурным сотрудником — это круглосуточная напряжённая работа. Несмотря на все ваши усилия и старания, есть вероятность упустить какое-либо уведомление. Однако команды, обслуживающие критически важные системы, не могут допустить пропуска оповещений об отключениях или перебоях в обслуживании. Правила эскалации являются страховочным механизмом для подобных ситуаций. Они включают в себя шаги с определёнными временными рамками, благодаря которым событие автоматически перенаправляется на ответственного сотрудника из следующего шага, если тот, кто был на предыдущем шаге, не обработал событие. Чтобы защитить свою компанию от пропущенных критических оповещений, создайте правила эскалации в проекте GitLab с расписанием дежурных сотрудников.
В релизе GitLab 14.1 пользователи могут создавать, просматривать и удалять правила эскалации.
Документация по правилам эскалации и оригинальный эпик.
CI/CD-тоннель для кластеров Kubernetes
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
До сих пор подключение кластеров Kubernetes к GitLab CI/CD требовало от пользователей открывать свои кластеры для GitLab. Некоторые организации не поощряют открытие своего фаервола для внешнего доступа по соображениям безопасности.
GitLab теперь включает в себя CI/CD-тоннель, который соединяет обработчики заданий GitLab с вашим кластером Kubernetes с помощью агента для Kubernetes от GitLab. Это позволяет создавать универсальные рабочие процессы GitOps, в которых логика развёртывания может быть заложена в конвейере (в русской локализации GitLab «сборочная линия»).
Вы и ваша команда можете спокойно работать с вашим любимым инструментом для запуска самого развёртывания, используя kubectl, helm, kpt, tanka или что-то другое без угрозы безопасности.
Чтобы использовать тоннель, определите kubecontext в вашем конвейере CI/CD для соединения с агентом. Чтобы упростить этот процесс, мы планируем автоматически добавлять kubecontext в CI/CD-окружение в будущих итерациях.
В настоящее время тоннель CI/CD поддерживается только из проекта, в котором был настроен агент, но мы работаем над добавлением поддержки на уровне группы. Вы можете смело начинать использовать тоннель на GitLab SaaS и в инстансах с самостоятельным управлением.
Документация по CI/CD-тоннелю и оригинальный эпик.
Новое правило подтверждения мерж-реквестов для покрытия кода
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Чтобы сохранить высокое покрытие кода тестами, необходимо убедиться, что мерж-реквесты (в русской локализации GitLab «запросы на слияние») в вашем проекте никогда не уменьшают покрытие тестами. Ранее единственным способом обеспечить это было требование подтверждения от пользователей, которые вручную проверяли изменение покрытия в рамках ревью.
Теперь вы можете обеспечить соблюдение ваших правил по покрытию с помощью нового правила подтверждения — проверки покрытия. Это простой способ убедиться, что мерж-реквесты, которые уменьшают покрытие тестами, не будут приняты.
Документация по правилу подтверждения Coverage-Check и оригинальный тикет.
Интеграция с Datadog CI Visibility
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Интеграция GitLab с Datadog Continuous Integration Visibility обеспечивает подробную аналитику ваших конвейеров, юнит-тестов и интеграционных тестов. Просматривайте изменения высокоуровневых метрик с течением времени: статусы выполнения, продолжительность, процентили (50-й и 95-й), количество сбоев, время ожидания в очереди и многое другое. Панели Datadog помогут вам разобраться в данных GitLab CI/CD и выявить проблемные задания, которые чаще всего приводят к сбоям конвейеров.
Документация по интеграции с Datadog CI Visibility и оригинальный тикет.
Создавайте таблицы и загружайте изображения через редактор вики-контента
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Мы начали улучшать возможности редактирования вики в релизе GitLab 14.0, когда представили MVC нового WYSIWYG-редактора Markdown. Он поддерживал наиболее распространённые возможности форматирования Markdown-контента, но с некоторыми существенными пробелами. GitLab 14.1 продолжает совершенствовать возможности редактирования, добавляя к ним изображения и таблицы. Теперь вы можете загружать изображения непосредственно в редактор, а также вставлять и редактировать таблицы, в том числе копировать и вставлять содержимое из популярных приложений для работы с электронными таблицами для переноса таблиц из других источников в вашу вики.
Документация по редактору контента для вики и оригинальный тикет.
Выбирайте роль для токена доступа к проекту
(SaaS: PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при создании токена доступа к проекту пользователи могут указать уровень доступа на уровне проекта, который у него должен быть, а также просматривать существующие роли токенов доступа к проекту.
До этого релиза все токены доступа к проекту были с ролью мейнтейнер (в русской локализации GitLab «сопровождающий»). Для некоторых пользователей эта роль включала расширенные права доступа, которые не были необходимы.
Чтобы исключить злоупотребления полномочиями, мы сделали выбор ролей для токенов проекта доступным для всех пользователей, за исключением бесплатных аккаунтов GitLab SaaS. Все пользователи инстансов с самостоятельным управлением, а также клиенты Premium и Gold SaaS теперь могут легко выбрать или узнать текущую роль для своих токенов доступа к проекту.
Документация по токенам доступа к проекту и оригинальный тикет.
Внешние проверки статуса для мерж-реквестов
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы можете обратиться к внешнему API для проверки статуса в мерж-реквесте. Это отличный способ интегрировать GitLab со сторонними системами, которые:
- Работают во внешней системе и не имеют специальных заданий на конвейере;
- Требуют ручного подтверждения в другой системе.
В проекте можно настроить API для проверки статуса (с помощью пользовательского интерфейса GitLab или API GitLab), а затем, когда в мерж-реквест вносятся изменения, этот API вызывается с различными подробностями о мерж-реквесте. Внешний API может вернуть код ответа, показывающий, прошла ли проверка. Этот результат будет показан в мерж-реквесте.
Это позволяет командам легче взаимодействовать друг с другом и убедиться, что мерж-реквесты соответствуют внешним требованиям, до их мержа, предоставляя ещё один метод обеспечения соответствия требованиям.
Документация по проверкам статуса для мерж-реквестов и оригинальный эпик.
Быстрый доступ к записям отчётов о соответствии
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Мы добавили на панель соответствия требованиям (Compliance Dashboard) новую информацию, быстрый доступ к подробностям мерж-реквеста для просмотра их состояния. Нажмите на мерж-реквест в списке, и вы увидите справа панель с информацией. Теперь вы сможете быстро узнать статус и просмотреть детали мерж-реквеста прямо на панели соответствия.
Это поможет сэкономить время, поскольку добавляет к панели соответствия информацию о каждом мерж-реквесте, такую как автор, название, подтверждающие, комментаторы и т.д. Вам больше не придётся открывать каждый мерж-реквест по отдельности, чтобы получить эту информацию. Команды, отвечающие за соблюдение требований, смогут оперативно ознакомиться с полным списком мерж-реквестов и найти те, которые требуют внимания, вместо того чтобы тратить время на проверку тех, которые в этом не нуждаются.
Документация по панели соответствия требованиям и оригинальный тикет.
Требование наличия связанного с мерж-реквестом тикета Jira
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы можете настроить в проекте обязательное связывание с тикетом из Jira для всех мерж-реквестов. Это отличный способ гарантировать, что изменения кода в GitLab будут отражены в тикетах Jira, и команды смогут лучше взаимодействовать друг с другом.
Документация по настройке требования связанного с мерж-реквестом тикета Jira и оригинальный эпик.
Лёгкая настройка DAST через интерфейс
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Динамическое тестирование безопасности приложений (DAST) в GitLab теперь предлагает новую упрощённую схему настройки. Мы считаем, что безопасность — это командная работа, и такая схема настройки облегчает работу с GitLab DAST пользователям, не являющимся экспертами в CI. Этот инструмент помогает пользователю создать мерж-реквест для запуска DAST-сканирования, задействуя при этом лучшие методы конфигурации, такие как использование управляемого GitLab шаблона DAST.gitlab-ci.yml и корректное переопределение настроек по умолчанию.
При использовании DAST в GitLab пользователи часто создают несколько конфигураций, чтобы охватить различные области своего приложения. Новый интерфейс конфигурации DAST позволяет пользователям создавать профили сайта и сканера DAST. Далее на эти профили можно ссылаться в заданиях конвейера CI/CD. Конфигурация хранится в базе данных и используется во время выполнения сканирования для загрузки переменных конфигурации в задание. Единственное, что пользователю надо будет настроить в конфигурации YAML — это указать названия профилей сайта и сканера, которые будут использоваться при сканировании. Благодаря этому становится максимально просто переключать конфигурации, когда этого требует ваше приложение. Создавать конфигурационные файлы YAML для ваших заданий DAST с нуля больше не требуется. Мы можем создать их за вас.
Документация по настройке DAST-сканирований и оригинальный эпик.
Встроенные уведомления о качестве кода в диффах мерж-реквестов
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Verify
Если вы разработчик, создающий или проверяющий мерж-реквест, вы хотите знать, как каждое изменение влияет на качество проекта. Чтобы достичь этого в GitLab, раньше требовалось открыть два окна:
- Дифф кода мерж-реквеста
- Главную страницу мерж-реквеста с изменениями качества кода.
Такое постоянное переключение неэффективно, и из-за него можно легко упустить проблемы с качеством кода.
Вкладка Изменения (Changes) в мерж-реквесте теперь показывает, в какой строке нарушилось качества кода, и степень его серьёзности, что позволит вам быстро определить наиболее важные проблемы, требующие решения. Наведя курсор на значок, вы получите подробную информацию о нарушении.
Документация по проверке качества кода в мерж-реквестах и оригинальный тикет.
Другие улучшения в GitLab 14.1
События аудита для созданных через API ключей GPG и SSH
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при создании с помощью API GPG-ключа или SSH-ключа создаются события аудита. Так вы будете знать не только о пользователях, создающих ключи через интерфейс GitLab, а обо всех созданных ключах, и сможете определить и защитить все способы доступа к GitLab.
Документация по событиям аудита в инстансе и оригинальный тикет.
События аудита для добавления новых администраторов инстанса
(self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при добавлении нового пользователя в качестве администратора инстанса GitLab создаётся новое событие аудита. Таким образом для каждого пользователя, ставшего администратором (то есть получившего право на внесение изменений в инстанс), в журнале аудита появляется запись о повышении уровня разрешений, которую впоследствии можно будет проверить.
Документация по событиям аудита инстанса и оригинальный тикет.
События аудита для изменения набора правил по соответствию требованиям для проекта
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
При изменении набора правил по соответствию требованиям для проекта теперь также создаются события аудита. Это позволит вовремя заметить возможные злоупотребления правилами управления ваших проектов.
Документация по событиям аудита проекта и оригинальный тикет.
Email-уведомления при деактивации пользователей
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь пользователи получают email-уведомления, когда их учётные записи деактивируются. Это позволит пользователям:
- Предпринять действия по восстановлению аккаунта;
- Понять, почему они больше не получают никаких уведомлений от GitLab;
- Понять, почему они не могут получить доступ к API и репозиториям в GitLab.
Документация по активации и деактивации пользователей и оригинальный тикет.
Миграция групп теперь включает эпики
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Недавно введённая фича GitLab, миграция групп, теперь включает в миграцию эпики со всей важной информацией, такой как метки, комментарии, события и эмодзи наград. Существующие пользователи соотносятся с теми, которые включены в группу, и назначаются на выполнение эпиков. Добавление эпиков — это важный шаг в разработке альтернативы фиче группового экспорта/импорта на основе файлов.
Документация по импорту групп и оригинальный эпик.
Предупреждение о потере доступа для внешних пользователей перед синхронизацией с протоколом LDAP
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Пользователи теперь получают предупреждение при попытке синхронизовать группы через LDAP. Как только группы синхронизуются через LDAP, все пользователи, внешние по отношению к группе LDAP, потеряют доступ. Таким образом, пользователи будут знать о последствиях такой синхронизации и будут иметь возможность сделать выбор.
Документация по управлению групповым членством через LDAP и оригинальный тикет.
Логирование числа объектов, импортированных с GitHub
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при импорте проектов с GitHub логи будут содержать число всех импортированных объектов. Эта информация поможет пользователям проверять импортированные данные и решать возможные проблемы импорта.
Документация по логированию импорта с GitHub и оригинальный тикет.
Отслеживание прогресса по внедрению DevOps
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы сможете посмотреть общее число ключевых фич DevOps, внедрённых в вашей организации, при помощи новой шкалы прогресса в разделе DevOps Adoption. Индикаторы прогресса помогут вам понять ценность, которую команды получают от использования GitLab, и оценить состояние вашего перехода к DevOps.
Документация по внедрению DevOps и оригинальный тикет.
Отображение местоимений пользователя во всплывающем окне
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage
Теперь при наведении на имя пользователя в тикете или мерж-реквесте вы будете видеть их местоимения во всплывающем окне с краткой информацией. Это поможет отвечать на комментарии, используя корректные местоимения, без необходимости переходить на страницу пользователя.
Документация по добавлению местоимений и оригинальный тикет.
Checkout веток мерж-реквестов в Visual Studio Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
При ревью мерж-реквестов в Visual Studio Code вам может потребоваться сделать checkout ветки, в которой предлагаются изменения. Искать имя исходной ветки и переключать контекст, чтобы сделать checkout, может быть неудобно.
Теперь при ревью мерж-реквеста через GitLab Workflow для Visual Studio Code, вы можете кликнуть правой кнопкой мыши по названию мерж-реквеста, чтобы сделать checkout его исходной ветки. Это упрощает ревью предлагаемых изменений в более широком контексте, локальное тестирование и другие действия над исходной веткой.
Документация по ревью мерж-реквестов и оригинальный тикет.
Создание и применение патчей в VS Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
При ревью мерж-реквестов может быть удобно предлагать исправления для сразу нескольких изменяемых файлов. Для этого обычно создают патч-файл со всеми предложениями и делятся им с другими пользователями. Проблема в том, что для этого нужно выполнить вручную несколько шагов: запустить команды Git и загрузить патч-файл туда, откуда другие смогут его скачать.
С версией 3.26.0 плагина GitLab Workflow для VS Code вы теперь можете создавать и применять патчи прямо в вашем редакторе. Новая команда GitLab: Create snippet patch создаёт патч с изменениями в вашем редакторе и загружает его как сниппет GitLab.
Любой пользователь может искать патчи среди сниппетов проекта и при помощи команды GitLab: Apply snippet patch применять их прямо в VS Code. Затем можно сделать коммит этих изменений в мерж-реквесте.
Обмен патчами и совместная работа с ними — это отличный способ предлагать более масштабные и понятные улучшения. Патчи, созданные в VS Code, можно связывать с другими через сниппеты, а также скачивать и применять вне VS Code для пользователей с другими инструментами редактирования.
Документация по созданию и применению патчей и оригинальный тикет.
Индикатор наличия комментариев при ревью мерж-реквестов в VS Code
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Ранее при ответе на фидбек к мерж-реквесту в Visual Studio Code было сложно понять, к каким файлам были оставлены комментарии. Приходилось вручную открывать каждый файл и искать в нем комментарии.
В версии 3.24.0 плагина GitLab Workflow для VS Code появился индикатор для файлов мерж-реквестов, содержащих комментарии. Это поможет вам легко определять файлы, для которых, возможно, необходимо просмотреть комментарии и провести ревью.
Документация по ревью мерж-реквестов и оригинальный тикет.
Отслеживание использования сканирований безопасности среди команд
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Manage
Теперь вы можете отслеживать, какие группы в вашей организации включили сканирования SAST и DAST. Это полезно для проверки соблюдения требований организации, ответа на запросы аудита и отслеживания прогресса по повышению безопасности приложений. Для отслеживания прогресса внедрения сканирований перейдите на вкладку Sec в разделе DevOps Adoption на уровне группы или инстанса.
Чтобы увидеть группы, которые включили фаззинг-тестирование и сканирование зависимостей, используйте API DevOps Adoption. Фаззинг-тестирование и сканирование зависимостей будут добавлены в пользовательский интерфейс DevOps Adoption в одном из будущих релизов.
Документация по внедрению DevOps и оригинальный тикет.
Редирект при переименовании основной ветки
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
В рамках нашей работы по переименованию основной ветки с master на main мы добавляем автоматический редирект, чтобы упростить этот переход. Ранее, когда в проекте менялось название основной ветки, URL с именем этой ветки вели на 404 Not Found, а это неприятно. Теперь, если вы перейдёте к файлу или директории, чья основная ветка была переименована, вы будете автоматически перенаправлены на новый адрес.
Документация по редиректу при изменении имени основной ветки и оригинальный тикет.
Отображение файлов формата CSV в удобном табличном виде
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Данные в файлах типа CSV (comma-separated value — значения, разделённые запятыми) проще читать, если они отображаются в виде таблицы со строками и столбцами, особенно при больших размерах файлов. Ранее данные CSV отображались в репозиториях GitLab как сырой текст. Теперь они отображаются в виде таблиц, а в режиме “Raw” по-прежнему можно увидеть исходный CSV-текст.
Документация по CSV-файлам и оригинальный тикет.
Корректное выделение якорных ссылок в формате GitHub
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Прямые ссылки на одиночную подсвеченную строку кода или текста помогают совместной работе над конкретной строкой, но в обсуждениях пользователи часто ссылаются на несколько строк кода или текста. Некоторые плагины для редактирования кода, такие как GitLink для сред разработки от JetBrains, генерируют якорную ссылку из выбранного диапазона из нескольких строк. Ранее вы не могли использовать такие ссылки в репозиториях GitLab, потому что GitLab и GitHub имеют несовместимые форматы для подсветки многострочных якорных ссылок. Добавить подсветку нескольких строк можно было только изменяя вручную URL в GitLab. Теперь GitLab поддерживает форматы GitHub для подсветки многострочных якорных ссылок.
Документация по разработке с GitLab и оригинальный тикет.
Новые типы контента в редакторе контента вики
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
В GitLab 14.0 мы представили редактор контента вики — новый WYSIWYG редактор разметки с поддержкой основных типов контента: жирный текст, курсив, код, цитирования и ссылок. В версии 14.1 мы добавляем текст с зачёркиванием и горизонтальные разделители. Добавление этих популярных типов контента приближает нас к нашей цели — предоставить всем пользователям широкие возможности редактирования без необходимости учить языки разметки, а также обеспечить полную поддержку GitLab Flavored Markdown, чтобы сделать новый редактор основным способом редактирования вики.
Документация по редактору контента вики и оригинальный эпик.
Настройка отображения абсолютного времени
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
GitLab во многих местах показывает относительное время (например, 30 минут назад). Теперь при желании вы можете изменить свой пользовательские настройки для отображения абсолютного времени вместо относительного, например ‘May 18, 2021, 3:57 PM’.
Абсолютное время учитывает ваши настройки браузера и формат даты и времени на основе предпочитаемых локалей, например, британский английский вместо американского. Этот новый формат отображения позволит получать больше информации с одного взгляда, что пригодится пользователям, которым нужно знать дату и время для использования в рабочих процессах, таких как сопоставление действий в GitLab с внешними системами.
Документация по настройкам времени и оригинальный тикет.
Доступ к библиотеке шаблонов CI/CD из редактора конвейера
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Шаблоны помогают новым пользователям познакомиться с GitLab CI/CD. В нашей библиотеке есть множество шаблонов, но доступ к ним не совсем интуитивен. В этом релизе мы добавили возможность перейти к библиотеке шаблонов прямо из редактора конвейера. Это упрощает поиск среди доступных шаблонов, так что вы сможете легко копировать и вставлять нужные участки кода в ваш файл настройки конвейера.
Документация по редактору конвейера и оригинальный тикет.
API GraphQL для обработчиков заданий по умолчанию включён
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: VerifyЯ
Ранее для автоматического управления обработчиками заданий вам приходилось извлекать и изменять данные при помощи REST API. Для повышения удобства администрирования обработчиков заданий в релизе 14.1 мы начинаем использовать GraphQL, который поможет улучшить интерфейс панели администратора обработчика заданий. Начиная с этого релиза вы сможете использовать запросы и мутации GraphQL, чтобы автоматизировать администрирование обработчиков заданий вашего инстанса GitLab.
Документация по GraphQL и оригинальный тикет.
Токены регистрации обработчика заданий скрыты на панели администратора
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Токен регистрации обработчиков заданий на уровне инстанса является конфиденциальной информацией. Если получить доступ к компьютеру администратора GitLab, можно скопировать этот токен и использовать его для добавления неавторизованных обработчиков заданий и получения секретных ключей из инстанса GitLab, когда обработчики выполняют задание. Мы решили скрыть этот токен, чтобы он отображался на экране только при необходимости.
Документация по регистрации обработчиков заданий и оригинальный мерж-реквест.
Ограничение регистрации обработчиков заданий для групп и проектов
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Сейчас по умолчанию вы можете регистрировать обработчики заданий на уровне группы и проекта в инстансе GitLab. Для некоторых организаций с более строгим управлением безопасностью администраторам важна возможность запрещать регистрацию обработчиков заданий. Вклад от участника нашего сообщества добавляет на панель администратора две настройки: для отключения регистрации на уровне проекта и группы. Для тестирования этой фичи вам нужно будет активировать переключаемую фичу (feature flag) :runner_registration_control.
Спасибо Thomas Watts за эту фичу!
Документация по регистрации обработчиков заданий и оригинальный мерж-реквест.
Обновление страницы обработчиков заданий на панели администратора
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Сейчас вы можете управлять всеми обработчиками заданий инстанса GitLab на странице обработчиков заданий на панели администратора. Однако возможностей, представленных на этой странице, недостаточно для администраторов GitLab, которые управляют большим числом обработчиков заданий. Начиная с этого релиза, страница обработчиков заданий на панели администратора будет использовать Vue.js и GraphQL. Список и страница подробной информации об обработчиках заданий теперь согласованы с другими областями пользовательского интерфейса GitLab. Эта новая архитектура даёт нам более интерактивный интерфейс, позволяет быстрее проводить итерации и добавлять новые фичи и возможности для администрирования большого числа обработчиков заданий. Это первая из множества запланированных итераций по улучшению панели администратора.
Документация по администрированию обработчиков заданий и оригинальный тикет.
Отслеживание CI-минут и квоты для публичных проектов
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Раньше вам было сложно точно оценить количество потраченных CI-минут, так как минутная квота не распространялась на публичные проекты. Поэтому мы добавили на страницу использования конвейера отображение времени, потраченного на CI публичными проектами. Это поможет вам получить более полную картину использования отведённых минут, чтобы принимать обоснованные решения об эффективном использовании конвейера. Эти временные квоты также помогают нашим попыткам остановить использование бесплатных минут для крипто-майнинга.
Также мы начинаем использовать квоты, чтобы ограничивать использование общедоступных обработчиков заданий в конвейерах публичных проектов. Для начала, квоты для публичных проектов будут применены ко всем новым пространствам имён, созданным после 17 июля. Все планы будут иметь квоту, а для новых пользователей плана Free публичные проекты будут иметь 50 000 минут использования общих обработчиков заданий.
Документация по CI-минутам и оригинальный тикет.
Реестр пакетов теперь поддерживает пакеты символов NuGet
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package
Вы можете использовать реестр пакетов GitLab для публикации и установки пакетов NuGet там же, где находятся ваш исходный код и конвейеры. Пакеты представляют собой наборы кода, поэтому иногда в них есть ошибки. Тогда как отлаживать NuGet? Часто для этого используют отладочные символы, в которых есть такая информация, как связь между скомпилированным и исходным кодом, имена локальных переменных, трассировки стека и другое.
Проблема в том, что, хотя GitLab поддерживает пакеты NuGet, пакеты символов (.snupkg) до недавнего времени не поддерживались. Это затрудняло совместное использование этих отладочных пакетов с вашей командой и не позволяло вам полагаться на GitLab как на единственный достоверный источник для ваших пакетов NuGet.
Теперь GitLab поддерживает публикацию и установку пакетов символов. Чтобы опубликовать пакет символов, просто запустите nuget push My.Package.snupkg -Source <source_name>. Затем вы можете загрузить файлы .snupkg через API или пользовательский интерфейс.
Документация по пакетам символов NuGet и оригинальный тикет.
Выбор ветки для работы в редакторе конвейера
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify
Раньше вы могли использовать редактор конвейера только для работы с конфигурацией конвейера в основной ветке проекта. В этом релизе мы добавляем в редактор конвейера выбор веток. Теперь вы можете использовать редактор конвейера из любой ветки, что значительно упрощает тестирование изменений перед их добавлением в ветку по умолчанию.
Документация по редактору конвейеров и оригинальный эпик.
Аутентификация для DAST на основе браузера
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
В рамках нашего проекта по переходу к экосистеме DAST на основе браузера мы переключили метод аутентификации DAST на аутентификацию на основе браузера. Помимо поддержки всех существующих методов аутентификации DAST, новая экосистема позволяет выполнять расширенную отладку с помощью создания отчёта, содержащего скриншоты и HTTP-запросы, сделанные в процессе аутентификации. Отчёт позволяет пользователю просмотреть все этапы процесса и увидеть, что происходит в случае сбоя аутентификации. Новый метод аутентификации также заметно облегчает настройку за счёт более гибкого выбора элементов формы входа на странице, поддержки отображения всплывающего модального окна входа в систему по нажатию на элементы формы, стратегии проверки успешности аутентификации и прямого доступа к логам браузера для отладки.
Документация по аутентификации для DAST и оригинальный тикет.
Бета-версия нового DAST-сканера безопасности API
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
В 2020 году GitLab приобрёл Peach Tech и в процессе получил невероятно мощный инструмент безопасности DAST API Security. Первоначально сосредоточившись на возможностях фаззинг-тестирования в приобретённых нами инструментах, сейчас мы с гордостью сообщаем, что DAST-сканер безопасности API теперь доступен в бета-версии. С этим сканером вы получаете сразу несколько преимуществ: включение большего количества методов спецификации API, поддержку большего количества языков API и дополнительные методы аутентификации. В дополнение к уже поддерживаемой спецификации OpenAPI вы также можете использовать коллекции Postman и файлы HAR, так что теперь есть несколько вариантов определения того, что может быть протестировано в API. Помимо поддержки REST API, новый сканер безопасности API также поддерживает конечные точки SOAP и GraphQL API. Дополнительные методы аутентификации включают статические файлы cookie, тела форм, тела JSON и тела XML. Динамические заголовки, файлы cookie, строки запроса, тела форм, тела JSON и тела XML теперь также поддерживаются с помощью пользовательских скриптов, обновляющих эти значения.
В рамках этой бета-версии задание DAST сканера безопасности API в конвейере CI/CD отделено от традиционного задания DAST для веб-приложения. Это задание можно настроить отдельно, используя новые переменные и новый шаблон YAML. Это значительное улучшение, которое позволяет использовать в одном конвейере DAST и для веб-приложений, и для API. Вам больше не нужно выбирать тип DAST-сканирования при тестировании приложений. Один конвейер может обеспечить покрытие приложения динамическими тестами безопасности как для пользовательского интерфейса, так и для API приложения.
Хотя этот новый сканер значительно расширяет наши возможности, мы заметили, что необходимо добавить ещё несколько проверок уязвимостей, чтобы сравняться по покрытию уязвимостей с текущим DAST-сканером API. Мы продолжим работу над этими проверками уязвимостей, чтобы довести сканер безопасности API до того уровня, на котором его можно выводить в общий доступ. В период бета-тестирования мы настоятельно рекомендуем попробовать новый сканер и приветствуем любые отзывы.
Документация по DAST-сканированию безопасности API и оригинальный эпик.
Сканирование зависимостей расширяет поддержку проектов Gradle
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Теперь вы можете включить сканирование зависимостей для ваших проектов на Java 16, собранных с Gradle. Установите значение переменной окружения DS_JAVA_VERSION в 16, чтобы использовать это улучшение. Кроме того, плагин gemnasium-gradle был обновлён для поддержки Gradle 7.0. Тикет для Gradle 7.0.
Документация по настройкам сканирования зависимостей и оригинальный тикет.
Обновления анализаторов SAST
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure
Статическое тестирование безопасности приложений (SAST) в GitLab включает в себя множество анализаторов безопасности, активно управляемых, поддерживаемых и обновляемых командой статического анализа GitLab. Ниже представлены обновления анализаторов, выпущенные в релизе 14.1. В этих обновлениях появилось расширенное покрытие, исправление ошибок и другие улучшения.
- Flawfinder обновили до версии 2.0.18: мерж-реквест, список изменений.
- Gosec обновили до версии 2.8.1: мерж-реквест, список изменений.
- Semgrep обновили до версии 0.57.0: мерж-реквест, список изменений:
- Установили тайм-аут 10 секунд для каждого файла;
- Исправили ошибки в шаблонах обнаружения;
- Новые шаблоны обнаружения.
- MobSF обновили до версии 2.13.0: мерж-реквест, список изменений. Удалили поддержку Python 3.8, чтобы уменьшить проблемы с безопасностью.
Если вы используете поставляемый GitLab шаблон SAST (SAST.gitlab-ci.yml), то вам не нужно ничего делать, чтобы получить эти обновления. Однако если вы переопределяете или используете свой собственный шаблон CI/CD, вам потребуется обновить конфигурации CI/CD. Если вы хотите использовать определённую версию любого анализатора, теперь вы можете закрепить минорную версию анализатора. Закрепление одной из предыдущих версий отменит автоматические обновления анализатора, и вам потребуется вручную менять версию анализатора в шаблоне CI/CD.
Документация по настройке анализаторов SAST и оригинальный тикет.
Инструмент настройки для поиска секретных ключей стал доступен всем
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Вслед за добавлением инструмента настройки статического сканирования безопасности GitLab в 13.12, мы добавляем поддержку обнаружения секретных ключей на страницу настроек безопасности. Мы уверены, что безопасность требует командной работы, и такая схема настройки упрощает начало работы с поиском секретных ключей в GitLab для пользователей, не являющихся экспертами в CI. Поэтому мы делаем этот инструмент доступным для всех пользователей SaaS в версии 14.1, а в ближайшее время — и для всех пользователей инстансов с самостоятельным
управлением. Этот инструмент поможет пользователю создать мерж-реквест для запуска поиска секретных ключей, используя при этом лучшие методы конфигурации, например шаблон SAST.gitlab-ci.yml под управлением GitLab. Инструмент настройки может создать новый файл .gitlab-ci.yml, если он не существовал, или обновить существующие простые файлы GitLab CI, что позволяет использовать этот инструмент с проектами, в которых уже настроен GitLab CI.
Документация по настройкам сканирований безопасности и оригинальный тикет.
Включайте сканирование зависимостей в пользовательском интерфейсе
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure
Пользователи с доступом к странице настроек безопасности и с ещё не настроенным сканированием зависимостей теперь могут включить его на этой странице, нажав «Настроить через мерж-реквест» (“Configure via Merge Request”). Это создаст или обновит ваш YAML-файл конвейера, добавив шаблон сканирования зависимостей по умолчанию. Теперь добавить сканирование зависимостей в ваш проект стало ещё проще, что дополнит ваш стандартный рабочий процесс разработки новым уровнем безопасности.
Документация по настройке сканирования зависимостей и оригинальный эпик.
Исправили разрешения на создание/редактирование/удаление релизов, соответствующие разрешениям на создание тегов
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В GitLab 14.1 мы обновляем разрешения на создание, редактирование или удаление релизов, чтобы они соответствовали разрешениям на создание тегов, и у всех пользователей был похожий опыт. Мы отдельно выделили это изменение, поскольку для проектов, релизы которых связаны с защищённым тегом, пользователь должен иметь доступ на запись как к релизам, так и к защищённым тегам, чтобы получить доступ к релизу. Если это изменение затрагивает вас, добавьте соответствующего пользователя в список Разрешено создавать (Allowed to create) в настройках защищённых тегов.
Документация по настройке разрешений для релизов и оригинальный тикет.
Интеграция Vault с поддержкой переменных окружения
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure
Пользователи Vault могут легко извлекать секретные ключи из GitLab CI/CD с помощью интеграции GitLab с Vault. Интеграция изначально создавала секретные переменные файлового типа (file), и у этого подхода было несколько недостатков. Чтобы устранить их, мы вводим новое ключевое слово file типа boolean, используя которое вы можете указать, надо ли хранить возвращаемую переменную как обычную переменную окружения (false) или как файл (true).
Для этой фичи требуется GitLab Runner версии 14.1.0. Для обратной совместимости по умолчанию переменные хранятся как переменные файлового типа (file: true).
Документация по настройке записи секретных ключей и оригинальный тикет.
Песочница по умолчанию отключена для GitLab Pages
(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
Теперь мы по умолчанию отключаем механизм chroot-песочницы для страниц GitLab из-за проблем, обнаруженных при обновлении до GitLab 14.0. Этот механизм больше не актуален, так как начиная с 14.0 мы перестали запускать GitHub Pages непосредственно с диска. Вы всё ещё можете включить песочницу, если вам это действительно нужно. В этом случае, пожалуйста, свяжитесь с нами в тикете обратной связи по миграции страниц, чтобы мы могли разобраться с вашим случаем.
Документация по настройке механизма песочницы и оригинальный тикет.
Связанные переключаемые фичи в тикетах
(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Release
В GitLab 13.2 мы добавили возможность связывать тикеты с переключаемыми фичами. В этом релизе теперь можно сделать и наоборот: связывать переключаемые фичи с тикетами. У тикета часто есть какой-то контекст, объясняющий, зачем это изменение было нужно. Когда пользователь может переходить от тикета к переключаемой фиче и обратно, он получает полный контекст того, для чего предназначена переключаемая фича.
Документация по связыванию тикетов и переключаемых фич и оригинальный тикет.
Поддержка UBI-образа для сканирования контейнера
(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect
GitLab теперь поддерживает версию образа для сканирования контейнеров, основанного на универсальном базовом образе (Universal Baseline Image, UBI). Сканирование контейнеров GitLab по умолчанию выполняется с помощью образа на основе Alpine. Однако вы можете предпочесть или потребовать, чтобы вместо этого оно выполнялось с помощью образа на основе UBI. Теперь вы можете выбрать, чтобы задания сканирования контейнеров выполнялись на таком образе, выполнив следующие шаги.
Документация по выбору образа для сканирования контейнеров и оригинальный эпик.
Программа Registration Features
(self-managed: FREE)
Для работающих под управлением GitLab EE инстансов с самостоятельным управлением под бесплатной лицензией, программа Registration Features вводит возможность получать доступ к платным фичам, регистрируясь в GitLab и предоставляя данные об активности через Service Ping. Фичи, представленные в программе, не убираются с соответствующих платных уровней, и платные пользователи всё ещё могут получать доступ к ним без предоставления данных об использовании. Первая такая фича — электронное письмо от GitLab — позволяет администраторам инстансов отправлять электронную почту пользователям их инстанса с панели администратора.
Документация по программе Registration Features и оригинальный эпик.
Обновления в обслуживании
Проблемы со сборкой мусора из-за несоответствующих образов контейнеров
Согласно спецификациям образов Docker и OCI, список манифестов должен ссылаться только на манифесты. Мы узнали, что можно отправлять списки манифестов, которые ссылаются на слои. Основная причина кроется в реализации в Docker’s Buildkit кэширования удалённых образов — напрямую или через Buildx. Об этом сообщали в тикете по Buildkit, но пока неизвестно, когда будет решена эта проблема. У нас есть краткосрочные и долгосрочные цели для работы с этой ситуацией.
В краткосрочной перспективе наша цель — разрешить для пользователей самостоятельно управляемых инстансов сборку мусора в офлайне. На данный момент мы обновили реестр контейнеров, чтобы учесть такое поведение.
В долгосрочной перспективе мы должны убедиться, что реестр контейнеров GitLab обеспечивает соблюдение спецификации образа OCI. Разрешение отправки списков манифестов с блобами влияет на целостность и согласованность данных. Однако добавление проверки внесёт несовместимые изменения для GitLab.com и для клиентов самостоятельных инстансов. Мы собираем данные о масштабах проблемы и в ближайшие месяцы разработаем план.
Тем временем, если у вас есть какие-либо вопросы, пожалуйста, задайте их в тикете.
Документация по сборке мусора в реестре контейнеров и оригинальный тикет.
Максимальный размер файла для логов заданий по умолчанию 100 МБ
GitLab ценит эффективность работы для всех пользователей нашего масштабного сообщества, поэтому мы всегда прилагаем максимум усилий, чтобы убедиться, что приложение работает на высоком уровне с привлекательным UX. В 14.2 мы планируем ввести предел для размера файла логов выполнения задания, по умолчанию это будет 100 мегабайт. Администраторы инстансов GitLab с самостоятельным управлением могут установить любое значение. Все задания, превышающие этот предел, отменяются и помечаются как неудачные, что помогает предотвратить снижение производительности или чрезмерное использование ресурсов. Это гарантирует, что использовать GitLab будет гораздо комфортнее.
Документация по настройке максимального размера файла для логов заданий.
Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте: GitLab 14.1 released with Helm Chart Registry and Escalation Policies.
Над переводом с английского работали @cattidourden, @maryartkey, @ainoneko и @rishavant.
