Картинка для привлечения внимания


Мы рады рассказать вам о выходе релиза GitLab 14.6, последнего релиза 2021-го года. В этом релизе появились: упрощённая конфигурация Geo, которая помогает распределённым командам ускорить выполнение git clone или git pull за счёт автоматического использования ближайшего к ним сервера; список действий агента GitLab, который регистрирует в реальном времени такие события, как состояние соединения и токена; различные улучшения для SAST, включая правила выполнения SAST-сканирований и поддержку .NET 6.


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


Приглашаем на наши встречи.


GitLab MVP badge


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


Благодаря Kev в релизе 14.6 были найдены и исправлены более десятка проблем с удобством (UX) GitLab. Многие из этих проблем относились к стадии Verify, но были также обновления для стадий Geo, Release и Create


Kev уже давно участвует в улучшении GitLab: начиная с релиза 13.1 было принято больше 240 мерж-реквестов. Спасибо за эту работу, Kev! ????


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


Бесперебойная работа по всему миру с Geo


(self-managed: PREMIUM, ULTIMATE) Доступность


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


В GitLab 14.6 вторичные сайты Geo явным образом проксируют запросы на запись на основной сайт, ускоряя при этом большинство запросов на чтение. Системные администраторы могут предоставить всем пользователям GitLab в своей организации единый URL, который автоматически будет обращаться к ближайшему к ним сайту Geo. Пользователям больше не нужно использовать различные конфигурации, чтобы воспользоваться преимуществами Geo, или беспокоиться о том, какие операции не будут работать на вторичных сайтах Geo. Распределённые команды оценят более быструю работу команд git clone и git pull и возможность бесперебойной работы по всему миру.


Вторичное проксирование и поддержка унифицированных URL по умолчанию включены для новых установок Geo. Вы также можете настроить унифицированный URL на существующей установке Geo и включить для неё вторичное проксирование.


Seamless worldwide performance with Geo


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


Запись действий агента GitLab для Kubernetes


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Configure


Мониторинг действий в вашем кластере помогает вам обнаружить и устранить неисправности, а также убедиться в успешном восстановлении рабочего состояния.


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


GitLab Agent's activity information


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


Удобное переключение редакторов вики


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


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


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



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


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


Отображение приватных вкладов на календаре вкладов


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage


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


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


Используйте API для переноса группы в новую родительскую группу


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage


В этом релизе мы добавили возможность переноса группы в новую родительскую группу через API групп. Ранее это можно было сделать только через пользовательский интерфейс. Теперь вы можете использовать Groups API для перемещения подгрупп в другую родительскую группу и для преобразования подгруппы в группу верхнего уровня.


Эта фича доступна администраторам и пользователям с:


  • Ролью владельца (Owner) для передаваемой группы
  • Разрешением на создание подгруппы в новой родительской группе при переносе группы
  • Разрешением на создание группы верхнего уровня при преобразовании подгруппы в группу верхнего уровня.

Use the API to transfer a group to a parent group


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


Копирование блоков кода в Markdown одним щелчком мыши


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan


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


Copy code blocks in Markdown with a single click


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


Более светлая обводка для иконок


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


Обновления для иконок продуктов GitLab:


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

Более подробную информацию можно найти в посте нашего продуктового дизайнера Jeremy Elder.


Lighter stroke-width for icons


Пост Jeremy Elder и оригинальный тикет.


Превью изменений, внесённых в строки с обсуждениями в мерж-реквестах


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


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


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


View inline the change that outdated a merge request thread


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


Очистка подов обработчика заданий GitLab


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify


Если у вас есть неиспользуемые поды Kubernetes от обработчиков заданий (runner), теперь вы можете использовать специальный инструмент, GitLab Runner Pod Cleanup, для их очистки. Эта утилита с открытым исходным кодом устанавливается в кластере Kubernetes вместе с менеджером обработчиков заданий GitLab Runner Manager и, когда она настроена, удаляет ненужные поды обработчиков в кластере. Эта новая утилита снижает затраты на обслуживание при использовании исполнителя Kubernetes для GitLab Runner.



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


Поддержка одновременного использования job:when и rules в CI/CD-конфигурациях


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify


Ранее было невозможно настроить задание в GitLab CI/CD с использованием ключевых слов rules и when на уровне задания. Требовалось добавлять when в каждую секцию rules, что могло приводить к объёмным конфигурациям с повторяющимися частями.


В релизе 14.6 мы избавились от этого ограничения, и теперь вы можете использовать ключевое слово when на уровне задания вместе с rules. Это делает удобнее использование when и упрощает создание конфигураций заданий.


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


Настройка правил очистки прокси зависимостей через пользовательский интерфейс


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package


Вы можете использовать прокси зависимостей GitLab, чтобы проксировать и кэшировать образы контейнеров из Docker Hub, что делает сборки более быстрыми и надёжными. Со временем ваша команда может добавить в кэш множество элементов, что приведёт к более высоким расходам на хранение.


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


Теперь вы можете настроить автоматические правила времени жизни (time-to-live, TTL) для прокси зависимостей прямо из пользовательского интерфейса. Чтобы сделать это, перейдите на странице групп в Настройки > Пакеты и реестры > Dependency Proxy (Settings > Packages & Registries > Dependency Proxy) и включите настройку для автоматического удаления элементов из кэша после 90 дней.


Enable Dependency Proxy cleanup policies from the UI


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


Использование токенов развёртывания для скачивания зависимостей Composer


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package


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


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


Поддержка SAST для .NET 6


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure


Релиз Microsoft .NET 6.0 — это следующий мажорный релиз .NET Core, в котором была значительно улучшена его производительность и появились новые возможности вычислений. Также этот релиз поддерживает упрощённый код .NET. Мы обновили наш анализатор .NET SAST, Security Code Scan, для поддержки этой новой версии, которая также теперь поддерживается нашим определителем языка для SAST, что позволяет GitLab SAST автоматически определять проекты .NET 6. Это изменение — вклад пользователя из нашего сообщества, @vasyl11 из Clay Solutions. Спасибо @vasyl11 за эту фичу!


Из-за проблем с обратной совместимостью, если вы хотите использовать сканирование SAST для .NET 6, вам нужно будет обновить файл .gitlab-ci.yml, чтобы сделать привязку к последней мажорной версии сканирования безопасности кода. Вы можете добавить этот сниппет в ваш файл .gitlab-ci.yml, чтобы попробовать новые возможности сканирования. В одном из будущих релизов мы объявим о предстоящем удалении в сканировании SAST всех версий .NET до 3.0 в связи с концом его срока жизни и последней датой поддержки от Microsoft. В GitLab 15.0 новая версия сканирования безопасности кода будет запускаться по умолчанию, что позволит выполнять сканирования .NET 5 и 6 SAST без необходимости включать экспериментальные фичи.


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


Поддержка настроек HTTPS прокси через RetireJS


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure


Благодаря вкладу от Ankur Sethi сканирование зависимостей теперь поддерживает настройки прокси в Retire.js через переменную окружения HTTPS_PROXY. Если HTTPS_PROXY задана, она будет передана в качестве опции командной строки для retire. Спасибо за эту фичу!


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


Автоматическое удаление Git-ссылок для старых развёртываний


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Release


По мере того, как проекты развёртываются, число развёртываний может значительно вырасти. Чтобы поддерживать высокую производительность команд Git, мы добавили автоматическое удаление Git-ссылок для старых развёртываний. Теперь GitLab будет хранить последние 50 000 развёртываний для каждого проекта и автоматически удалять Git-ссылки для всех остальных.


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


Результаты сканирования контейнеров в списке зависимостей


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect


Команды, отвечающие за безопасность и соответствие требованиям, а также разработчики должны иметь полную картину всех зависимостей, используемых в проекте. Задания по сканированию контейнеров теперь добавляют все идентифицированные системные зависимости в список зависимостей по умолчанию. Этот список системных зависимостей появляется вместе с любыми зависимостями приложений, определёнными заданием по сканированию зависимостей. Теперь пользователи могут просматривать полный список зависимостей проекта централизованно, в одном месте — на странице Безопасность и комплаенс > Список зависимостей (Security & Compliance > Dependency List).


Container Scanning results in the Dependency List


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


Правила выполнения сканирований SAST


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect


Пользователи теперь могут требовать выполнения сканирований SAST по регулярному расписанию или в рамках конвейеров (в русской локализации GitLab «сборочные линии») независимо от содержимого файла .gitlab-ci.yml. Это позволяет командам по безопасности управлять требованиями к сканированиям без выдачи разработчикам разрешений на изменение настроек. Вы можете начать работу с правилами безопасности на странице Безопасность и комплаенс > Политики (Security & Compliance > Policies). Чтобы настроить сканирования SAST, задайте в поле scan значение sast.


SAST scan execution policies


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


Geo верифицирует четыре дополнительных типа данных


(self-managed: PREMIUM, ULTIMATE) Доступность


GitLab хранит загрузки, объекты LFS, развёртывания GitLab Pages и диффы внешних мерж-реквестов в файловой системе или в хранилище объектов. Geo реплицирует эти данные на один или несколько вторичных сайтов для улучшения работы распределённых команд или в рамках стратегии аварийного восстановления. Теперь Geo автоматически верифицирует целостность хранящихся в файловой системе данных — реплицированных загрузок, объектов LFS, развёртываний GitLab Pages и диффов внешних мерж-реквестов. Это даёт гарантию того, что данные не были повреждены при передаче или хранении. Если вы используете Geo как часть стратегии аварийного восстановления, это обеспечит дополнительную защиту от потери данных.


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


Настройка максимального срока жизни ключа SSH


(self-managed: ULTIMATE) Стадия цикла DevOps: Manage


Администраторы теперь могут задавать максимальное количество дней, в течение которых будет действовать ключ SSH. Это особенно полезно для организаций, которые должны следовать строгим правилам истечения срока действия ключей в рамках правил соответствия требованиям. В GitLab уже была возможность задавать максимальное количество дней, в течение которых могут оставаться валидными личные токены доступа (PAT). Эта фича работает аналогичным образом.


To set this new limit, administrators can navigate to the Admin Area and select Settings > General. Find the new setting by expanding Account and limit to set Maximum allowed lifetime for SSH keys (in days).


Настроить новое ограничение можно через панель администратора, в разделе Настройки > Общие (Settings > General). Эта настройка находится в Аккаунт и ограничения (Account and limit), поле Максимально допустимый срок действия ключей SSH (в днях) (Maximum allowed lifetime for SSH keys (in days)).


Set maximum SSH key lifetime


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


Аутентификация через WebAuthn включена по умолчанию


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Manage


Аутентификация через WebAuthn поддерживается, но была отключена по умолчанию начиная с GitLab 13.4; теперь она включена по умолчанию. Пользователи смогут использовать Touch ID на устройствах Apple как второй фактор для двухфакторной аутентификации, если их браузер это поддерживает. Это также позволяет избавиться от сообщений об ошибке, которые появляются в браузерах, отказавшихся от U2F в пользу WebAuthn.


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


Отображение заголовка тикета в Markdown


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan


При добавлении ссылок на тикеты (в русской локализации GitLab «обсуждения»), эпики (в русской локализации GitLab «цели») или мерж-реквесты в полях с Markdown раньше не было способа добавлять дополнительный контекст кроме ID. Теперь вы можете добавлять + к тикету, эпику или мерж-реквесту, чтобы отобразить также заголовок.


Render the title of a referenced issue within markdown


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


Шаблон сообщения для объединения коммитов


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Create


Объединение (squash) коммитов — это отличный способ очищать историю коммитов мерж-реквеста, объединяя все коммиты при мерже. Просматривать историю веток становится проще, в то же время логика, стоящая за этими изменениями остаётся незатронутой. Раньше GitLab по умолчанию использовал заголовок мерж-реквеста в качестве сообщения при объединении коммитов. Если вы не редактировали сообщение перед мержем, то могли потерять важную информацию о внесённых изменениях.


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


Спасибо Piotr за этот невероятный вклад!


Squash commit message template


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


Причина неудачного завершения задания возвращается через API


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify


Использовать API для сбора данных о причине неудачного завершения задания может быть непросто, например, если вы хотите знать точные причины ошибки, чтобы более эффективно использовать ключевое слово retry:when.


Теперь в ответах от Jobs API появилась переменная failure_reason, с помощью которой собирать данные о причинах ошибки становится намного проще. Спасибо @albert.vacacintora за эту фичу!


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


Веб-хук теперь срабатывает для отложенных заданий


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Verify


Раньше было неудобно использовать веб-хуки событий в заданиях для мониторинга CI/CD, поскольку было трудно отслеживать множество отложенных (pending) заданий, которые могут существовать в проекте.


Теперь веб-хук инициирует событие, когда состояние задания изменяется на «отложено», поэтому больше не нужно применять обходные пути или специальные интеграции для отслеживания всех статусов задания.


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


Публикация пакетов Conan только с названием и версией


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Package


Предположим, вы используете репозиторий GitLab Conan для публикации и совместного использования ваших пакетов C/C++. При создании пакета Conan необходимо указывать четыре поля: name (имя), version (версия), user (пользователь) и channel (канал). Эти поля однозначно определяют пакет. Поля user и channel не обязательны в Conan 2.0, но GitLab требует, чтобы вы продолжали их использовать. Применение соглашений об именах в соответствии с требованиями GitLab вместо стандартов из Conan неэффективно и непрактично.


Мы обновили репозиторий GitLab Conan в соответствии с требованиями Conan. Теперь вы можете публиковать и загружать свои пакеты Conan как с полями user и channel, так и без них. Это улучшение повышает эффективность и упрощает поиск и проверку пакетов в пользовательском интерфейсе. Это изменение — первое из широкого набора запланированных улучшений в репозитории Conan, которые помогут перевести его из бета-версии в общий доступ.


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


Возможность комбинирования пользовательских наборов правил для SAST и поиска ключей


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure


Мы улучшаем возможности добавленных в GitLab 13.5 пользовательских наборов правил для SAST и поиска секретных ключей (оригинальная статья, перевод). Эти наборы правил позволяют адаптировать поведение анализаторов SAST и сканирования на ключи к предпочтениям вашей организации. Чтобы улучшить эту возможность, мы представляем возможность добавлять правила из нескольких источников, например из репозиториев Git и локальных файлов. С этим изменением становится проще создавать и управлять несколькими настраиваемыми наборами правил из разных мест, которые организации могут использовать для наследования правил из разных источников, и за счёт этого достигать большей гибкости. Мы рассказываем больше про эту новую фичу в посте в нашем блоге. Изначально это изменение доступно для наших анализаторов SAST Semgrep, Nodejs и Gosec и поиска секретных ключей. Мы добавим эту возможность в другие наши анализаторы в будущих релизах.


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


Обновления анализаторов SAST


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Secure


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



Если вы используете поставляемый GitLab шаблон SAST (SAST.gitlab-ci.yml), то вам не нужно ничего делать, чтобы получить эти обновления. Однако если вы переопределяете его или используете свой собственный шаблон CI, вам потребуется обновить конфигурации CI. Также вы можете закрепить минорную версию анализатора, чтобы использовать определённую версию любого анализатора. Закрепление одной из предыдущих версий отменит автоматические обновления анализатора, и вам потребуется вручную менять версию анализатора в шаблоне CI.


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


Использование DS_EXCLUDED_PATHS теперь приводит к предварительной фильтрации зависимостей


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Secure


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


Это изменение было внесено 2‑го декабря 2021 для gemnasium, 6-го декабря 2021 для gemnasium-python и 7-го декабря 2021 для gemnasium-maven. Это изменение применяется ко всем версиям, так как мы его бэкпортировали.


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


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


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


Быстрое действие для превращения тикета в инцидент


(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Monitor


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


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


Customize deduplication of container scanning vulnerabilities


Настройка дедупликации уязвимостей при сканировании контейнеров


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect


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


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


Отвязка проектов правил безопасности


(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Protect


Владельцы проектов теперь могут отвязать проекты правил безопасности от проектов разработки. Для этого сначала перейдите к Безопасность и комплаенс > Политики (Security & Compliance > Policies) и нажмите кнопку Изменить проект политики (Edit Policy Project). Затем выберите значок корзины, чтобы разорвать связь с ранее связанным проектом правил безопасности.


Unlink security policy projects


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


Улучшения удобства использования


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


В GitLab 14.6 мы поработали над тикетами, проектами, майлстоунами (в русской локализации GitLab «этапы») и многим другим. Мы особо выделяем следующие изменения в GitLab 14.6:





Полный текст релиза и инструкции по обновлению/установке вы можете найти в оригинальном англоязычном посте GitLab 14.6 adds seamless Geo experience and supports .NET 6 in SAST.


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

Комментарии (2)


  1. niyaho8778
    17.01.2022 18:17
    -7

    "(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) "

    да это цитата... господи гитлаб в чего ты превратился ....

    напоминает как будто 3 летний ребенок называет СуперМуперМегаАнигелейшенХардКул


    1. QtRoS
      18.01.2022 11:58
      +2

      Есть два типа развертывания: SaaS и Self-managed. Каждый из них доступен в трех тарифных планах: FREE, PREMIUM, ULTIMATE.

      Разве сложно?