Мы с радостью объявляем о релизе GitLab 18.0 c GitLab Duo в планах Premium и Ultimate, автоматическими ревью мерж-реквестов с Duo Code Review, улучшенным контекстом Duo Code Review, фичей Repository X-Ray, доступной для Gitlab Duo с самостоятельным хостингом и многими другими фичами!
Это лишь несколько из более 30 улучшений, добавленных в этом релизе. Читайте дальше, чтобы узнать обо всех основных изменениях.

Основные улучшения в GitLab 18.0

GitLab Duo в Premium и Ultimate

(SaaS: PREMIUM, ULTIMATE, DUO PRO, DUO ENTERPRISE; self-managed: PREMIUM, ULTIMATE, DUO PRO, DUO ENTERPRISE) Стадия цикла DevOps: AI-powered
Мы с радостью представляем GitLab Premium с Duo и GitLab Ultimate с Duo. GitLab Premium и Ultimate теперь включают наши нативные ИИ-фичи.
Эти фичи включают в себя предложения по коду и чат GitLab Duo, встроенные в среду разработки. Команды разработки могут использовать их, чтобы:

• анализировать, понимать и объяснять код,
• быстрее писать безопасный код,
• быстро генерировать тесты для поддержания качества кода,
• легко рефакторить код для улучшения производительности или использования определённых библиотек.

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

Фича Repository X-Ray теперь доступна для GitLab Duo с самостоятельным хостингом

(self-managed: PREMIUM, ULTIMATE, DUO ENTERPRISE) Стадия цикла DevOps: AI-powered
Теперь вы можете использовать фичу «рентген репозитория» (Repository X-Ray) для предложений по коду (Code Suggestions) в GitLab Duo с самостоятельным хостингом. Эта фича находится в бета-версии для GitLab Duo с самостоятельным хостингом, и доступна для всех в инстансах GitLab с самостоятельным управлением.
Документация по фиче Repository X-Ray и оригинальный эпик.

Автоматические ревью с Duo Code Review

(SaaS: PREMIUM, ULTIMATE, DUO ENTERPRISE; self-managed: PREMIUM, ULTIMATE, DUO ENTERPRISE) Стадия цикла DevOps: Create
Фича Duo Code Review даёт ценную информацию в процессе ревью, однако сейчас вам нужно вручную запрашивать ревью для каждого мерж-реквеста.
Теперь вы можете настроить автоматический запуск Duo Code Review для мерж-реквестов, обновив настройки мерж-реквестов вашего проекта. Когда эта фича включена, Duo Code Review автоматически выполняет ревью мерж-реквестов, кроме:

• мерж-реквестов в состоянии драфта;
• мерж-реквестов, которые не содержат изменений.
  Автоматические ревью позволяют убедиться, что весь код в вашем проекте прошёл через ревью, что стабильно повышает качество всего вашего кода.
  Документация по автоматическим мерж-реквестам GitLab Duo и оригинальный тикет.

Кэширование промптов Code Suggestions

(SaaS: PREMIUM, ULTIMATE, DUO PRO, DUO ENTERPRISE; self-managed: PREMIUM, ULTIMATE, DUO PRO, DUO ENTERPRISE) Стадия цикла DevOps: Create
Теперь при генерации кода фичей Code Suggestions выполняется кэширование результатов вводимых вами промптов. Это значительно снижает задержку при генерации кода, так как в дальнейшем промпт и входные данные не обрабатываются повторно. Кэшированные данные никогда не сохраняются в постоянное хранилище, и вы можете отключить кэширование в настройках GitLab Duo.

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

Улучшенный контекст Duo Code Review

(SaaS: PREMIUM, ULTIMATE, DUO ENTERPRISE; self-managed: PREMIUM, ULTIMATE, DUO ENTERPRISE) Стадия цикла DevOps: Create
При выполнении ревью кода Duo теперь учитывает более полный контекст изменений, чтобы лучше анализировать его результаты. Основные улучшения включают следующее:

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

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

Удаление групп и пользователей-«заглушек»

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

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

Поддержка нескольких рабочих пространств в GitLab для приложения в Slack

(self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Foundations
Приложение GitLab для Slack теперь поддерживает несколько рабочих пространств для пользователей GitLab с самостоятельным управлением и GitLab Dedicated. Это позволит организациям с несколькими Slack-пространствами поддерживать бесшовную интеграцию с GitLab для всех пространств. Чтобы включить эту фичу, настройте приложение GitLab для Slack как незарегистрированное распределённое приложение.
Документация по поддержке нескольких пространств и оригинальный тикет.

Улучшения шаблонов GitLab Pages

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Plan
GitLab предоставляет шаблоны для популярных генераторов статических сайтов. Мы подробно проанализировали доступные шаблоны с помощью фреймворка оценок, и сократили список, оставив в нем только самые популярные варианты.
Сокращение списка доступных шаблонов упрощает процесс создания сайтов. Используйте шаблоны, чтобы запускать профессионально выглядящие сайты, даже если вы не владеете нужными техническими навыками. Наши улучшенные шаблоны также предоставляют современный адаптивный дизайн, с которым вам больше не понадобится кастомная разработка.
Документация по шаблонам проектов и оригинальный эпик.

Разделяемые пространства имён Kubernetes для рабочих пространств GitLab

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Create
Теперь вы можете создавать рабочие пространства GitLab в разделяемом пространстве имён Kubernetes. Это позволит не создавать новое пространство имён для каждого рабочего пространства и не требовать повышенных разрешений ClusterRole для агента. С этой фичей вам будет проще внедрять рабочие пространства в защищённых и ограниченных окружениях, что, в свою очередь, упрощает масштабирование.
Чтобы включить разделяемые пространства имён, задайте в поле shared_namespace в файле настроек вашего агента имя для пространства имён Kubernetes, которое вы хотите использовать для всех рабочих пространств GitLab.

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

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

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Deploy
Вы можете использовать панель Kubernetes для мониторинга ваших развёрнутых приложений. До сих пор поды с ошибками контейнеров вида CrashLoopBackOff или ImagePullBackOff отображались со статусами “Pending” или “Running”, что усложняло определение проблемных развертываний без использования kubectl.
В GitLab 18.0 статусы ошибок в пользовательском интерфейсе отображают статус определённого контейнера аналогично выводу команды kubectl. Теперь вы можете быстро идентифицировать проблемные поды и найти причину ошибки, не покидая интерфейс GitLab.

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

Сканеры безопасности теперь поддерживают конвейеры мерж-реквестов

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

Теперь вы можете запускать сканеры тестирования безопасности приложений (Application Security Testing (AST)) в конвейерах мерж-реквестов. Чтобы эта фича минимально повлияла на ваши конвейеры, мы сделали её опциональной и управляемой.
Раньше поведение по умолчанию зависело от того, использовали ли вы стабильный или последний вариант шаблона CI/CD для включения сканера:

• В стабильных шаблонах задания сканирования запускаются только в конвейерах веток. Конвейеры мерж-реквестов не поддерживались.
• В последних шаблонах задания сканирования запускались в конвейерах мерж-реквестов, когда мерж-реквест был открыт, и в конвейерах веток, когда связанного мерж-реквеста не существовало. Вы не могли управлять этим поведением.
  Теперь новая опция AST_ENABLE_MR_PIPELINES позволяет вам управлять тем, должны ли задания выполняться в конвейерах мерж-реквеста. Поведение по умолчанию для стабильных и последних шаблонов не меняется. А именно:
• Стабильные шаблоны продолжают по умолчанию запускать задания сканирования в конвейерах веток. Однако вы можете задать AST_ENABLE_MR_PIPELINES: "true", чтобы использовать вместо этого конвейеры мерж-реквеста, если связанный мерж-реквест существует.
• Последние шаблоны продолжают по умолчанию запускать задания в конвейерах мерж-реквеста, если мерж-реквест существует. Однако вы можете задать AST_ENABLE_MR_PIPELINES: "false", чтобы вместо этого использовать конвееры веток.
  Это улучшение затрагивает все шаблоны сканирования безопасности кроме API Discovery (API-Discovery.gitlab-ci.yml), который сейчас по умолчанию использует конвейеры мерж-реквеста. Мы также изменили шаблон API Discovery, чтобы он соответствовал другим стабильным шаблонам в GitLab 18.0 и по умолчанию использовал конвейеры веток.
  Документация по использованию конвейеров мерж-реквестов для сканирований безопасности и оригинальный тикет.
  

  Настройка тикетов Jira, создаваемых из уязвимостей, через API интеграций проекта

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Security Risk Management
Ранее вам приходилось настраивать интеграцию для создания тикетов Jira из уязвимостей со страницы настроек проекта (Project settings).
Теперь вы можете делать это через API интеграций проекта, что позволяет автоматизировать процесс.
Документация по тикетам Jira и оригинальный тикет.

Улучшенное отслеживание уязвимостей, найденных повторно

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Security Risk Management
Ранее, если разрешённая уязвимость была обнаружена повторно и изменяла статус, в информации по уязвимости не было сведений о том, когда и почему это произошло.
Теперь GitLab добавляет системную заметку в историю уязвимости, когда разрешённые уязвимости меняют статус из-за того, что они появились в новом сканировании. Эта дополнительная информация поможет пользователям понять, почему уязвимость изменила статус.
Документация по статусам уязвимостей и оригинальный тикет.

Отображение и фильтрация архивных проектов в отчёте по проектам с соответствием требованиям

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security
В отчёте по проектам, следующим правилам соответствия требованиям, вы можете просматривать фреймворки соответствия, применяемые к проектам в группе или подгруппе.
Однако ранее этот отчёт не давал информации о том, архивный ли это проект, что могло быть полезно для управления соблюдением требований в активных и архивных проектах.
Поэтому мы добавили индикатор, который показывает, что проект архивный. Это даст вам больше наглядности и контекста при просмотре фреймворков в активных и архивных проектах.
Эта фича включает:

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

  LDAP аутентификация с именем пользователя GitLab

(self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security
Пользователи, использующие протокол LDAP, теперь могут выполнять аутентификацию при выполнении запросов, используя своё имя пользователя GitLab. Ранее, если имена пользователя в GitLab и в LDAP не совпадали, GitLab возвращал ошибку аутентификации. Данное улучшение поможет пользователям поддерживать разные правила создания имён пользователей в GitLab и LDAP без нарушения рабочих процессов согласования.
Документация по LDAP и оригинальный тикет.

Новые разрешения для кастомных ролей

(SaaS: ULTIMATE; self-managed: ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security
Вы можете создавать кастомные роли с разрешением на управление защищёнными окружениями. Кастомные роли позволяют вам выдавать только определённые разрешения, которые нужны пользователям для выполнения заданий. Это помогает определять роли в соответствии с нуждами вашей группы и может снизить число пользователей с ролями Owner или Maintainer.
Документация по кастомным ролям и оригинальный эпик.

Отложенное удаление проекта для пользовательских пространств

(SaaS: FREE, PREMIUM, ULTIMATE; self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Tenant Scale
Отложенное удаление проекта теперь доступно для проектов в пространствах имён пользователей (личных проектах). Ранее эта защита от случайной потери данных была доступна только для пространств имён групп. Теперь, когда вы удаляете проект в вашем пользовательском пространстве, он перейдёт в состояние «ожидает удаления» (pending deletion) на срок, определённый в настройках вашего инстанса (на GitLab.com — 7 дней), а не удалится сразу. Это создаёт дополнительное окно времени, в течение которого вы можете при необходимости восстановить проект.
Мы надеемся, что это улучшение поможет вам меньше переживать о возможной потере данных при управлении своими личными проектами на GitLab.

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

Релиз GitLab chart 9.0 с критическими изменениями

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

• Критическое изменение](https://docs.gitlab.com/update/deprecations/#postgresql-14-and-15-no-longer-supported): Поддержка PostgreSQL 14 и 15 была удалена. Перед обновлением убедитесь, что вы используете PostgreSQL 16.

  
  

• Критическое изменение: Встроенный чарт Prometheus был обновлён с 15.3 до 27.11. Также была обновлена версия Prometheus с 2.38 до 3.0. Для выполнения обновления необходимо выполнить некоторые действия вручную. Если у вас включены Alertmanager, Node Exporter или Pushgateway, необходимо также обновить значения для Helm. Дополнительные сведения можно найти в руководстве по миграции.

  
  

• Критическое изменение: Дефолтный образ контроллера NGINX был обновлён с версии 1.3.1 до 1.11.2. Если вы используете чарт NGINX от GitLab и установили свои собственные правила RBAC для NGINX, новые правила RBAC должны существовать. Дополнительные сведения можно найти в руководстве по обновлению.

  
  

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

Внутренние релизы теперь доступны для GitLab Dedicated

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

Клиентам GitLab Dedicated, которые ценят безопасность и обязательства по соблюдению требований, требуется самый высокий уровень защиты для их сред разработки. Теперь мы представляем внутренние релизы (Internal Releases) — новый приватный релиз, который позволяет нам устранять критические уязвимости инстансов GitLab Dedicated до их публичного раскрытия, гарантируя, что клиенты GitLab Dedicated никогда не будут подвержены им. Эта новая возможность обеспечивает немедленную защиту от критических уязвимостей, обнаруженных в GitLab, параллельно с реагированием на GitLab.com. Этот новый процесс не требует действий со стороны клиента.

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

Новый параметр active для REST API групп и проектов

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

Мы добавили новый параметр active в наши REST API для групп и проектов. Он упрощает фильтрацию групп на основе их статуса. Если установлено значение true, то возвращаются только неархивированные группы или не отмеченные для удаления проекты. Если установлено значение false, возвращаются только архивированные группы или отмеченные для удаления проекты. Если параметр не определён, фильтрация не применяется. Это улучшение поможет вам эффективно управлять рабочими процессами, нацеливаясь на определённые статусы с помощью простых вызовов API.

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

Показ только пользователей Enterprise для переназначения вкладов на GitLab.com

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

В этом релизе мы улучшили сопоставление пользователей-«заглушек», ограничив раскрывающийся список выбора пользователей только до пользователей Enterprise, связанных с группой верхнего уровня. Ранее при переназначении вкладов пользователей после импорта на GitLab.com вы видели в раскрывающемся списке всех активных пользователей платформы, что затрудняло определение правильного пользователя, особенно когда SCIM-подготовка изменяла имена пользователей. Теперь, если ваша группа верхнего уровня использует фичу «пользователи Enterprise», в раскрывающемся списке будут отображаться только пользователи, заявленные вашей организацией, что значительно снижает вероятность ошибок при переназначении пользователей. Такое же определение области действия применяется и к переназначению на основе CSV, предотвращая случайное назначение пользователям за пределами вашей организации.

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

Улучшения представлений языка запросов GitLab

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

Мы значительно улучшили представления на языке запросов GitLab (GLQL). Эти улучшения поддерживают:

• операторы >= и <= для всех типов дат,
• выпадающий список Просмотр действий (View actions) в представлениях,
• действие Перезагрузить (Reload),
• псевдонимы полей,
• присвоение столбцам псевдонима с кастомным именем в таблицах GLQL.

Мы будем рады вашим отзывам об этом улучшении и о представлениях GLQL в целом в тикете 509791.

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

Создание рабочего пространства из мерж-реквестов

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

Теперь можно создать рабочую область сразу из мерж-реквеста с помощью новой опции Открыть в рабочей области (Open in Workspace). Эта фича автоматически настраивает рабочее пространство с учётом ветки и контекста мерж-реквеста, позволяя вам:

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

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

Просмотр открытых мерж-реквестов, касающихся определённых файлов

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

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

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

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

Значок отображает количество открытых мерж-реквестов, изменяющих файл, а при наведении на него открывается всплывающее окно со списком этих мерж-реквестов.

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

Новое представление аналитики CI/CD для проектов с ограниченной доступностью

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

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

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

Сбор данных о событиях

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

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

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

Массовое добавление уязвимостей к тикетам из отчёта об уязвимостях

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

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

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

Исключение пакетов из правил подтверждения лицензий

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

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

Раньше в политиках подтверждения лицензий, если вы блокировали лицензию, например AGPL-3.0, она блокировалась для всех пакетов в вашей организации. Это создавало проблемы, когда:

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

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

• Определять исключения для конкретных пакетов в правилах подтверждения лицензий с помощью формата URL пакета (PURL).
• Разрешить определённым пакетам (или версиям пакетов) использовать лицензии, ограниченные в общем случае.
• Запретить использование определённым пакетам (или версиям пакетов) в целом разрешённых лицензий.

Чтобы добавить исключения, выполните следующие действия при создании или редактировании политики подтверждения лицензий:

1. В своей группе перейдите в Безопасность и соответствие > Политики (Security & Compliance > Policies)
2. Создайте или отредактируйте политику подтверждения лицензий.
3. Найдите новые параметры исключений пакетов в визуальном редакторе или настройте их в режиме YAML.
4. Выберите режим белого или чёрного списка для лицензий.
5. Добавьте определённые лицензии в свою политику.
6. Для каждой лицензии определите исключения из пакетов в формате PURL (например, "pkg:npm/@angular/[email protected]").
7. Укажите, следует ли включать или исключать эти пакеты из правила лицензирования.

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

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

Отключение приглашений пользователей

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security

Теперь можно отключить возможность приглашать участников в группы или проекты.

• На GitLab.com этот параметр настраивается владельцами групп с корпоративными пользователями и применяется к любым подгруппам или проектам в группе верхнего уровня. Ни один пользователь не может отправлять приглашения, пока этот параметр включён.

  
  

• На GitLab с самостоятельным управлением этот параметр настраивается администраторами и применяется ко всему инстансу. Сами администраторы по-прежнему могут приглашать пользователей напрямую.

  
  

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

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

Детализированные разрешения для токенов заданий в бета-версии

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

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

С нашей новой фичей (пока в бета) Детализированные разрешения для токенов заданий теперь можно точно контролировать, к каким конкретным ресурсам токен задания может получить доступ в проекте. Это позволяет вам реализовать принцип наименьших привилегий в ваших рабочих процессах CI/CD, предоставляя каждому заданию только минимальный доступ, необходимый для выполнения его задач.

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

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

Ограничение максимальной продолжительности сеанса пользователя

(self-managed: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security

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

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

Поддержка сертификатов SAML SHA256

(SaaS: PREMIUM, ULTIMATE; self-managed: PREMIUM, ULTIMATE) Стадия цикла DevOps: Software Supply Chain Security

Теперь GitLab автоматически определяет и поддерживает отпечатки сертификатов SHA1 и SHA256 для групповой SAML-аутентификации. При этом сохраняется обратная совместимость с существующими отпечатками SHA1 и добавляется поддержка более безопасных отпечатков SHA256. Это обновление необходимо для подготовки к предстоящему релизу ruby-saml 2.x, в котором SHA256 будет использоваться по умолчанию.

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

Защита от удаления доступна для всех пользователей

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

Отложенное удаление проектов и групп теперь доступно для всех пользователей GitLab, в том числе для пользователей с планом Free. Эта важная фича безопасности добавляет период (7 дней на GitLab.com) до того, как удалённые группы и проекты будут удалены окончательно. Эта фича позволяет избежать сложных операций восстановления после случайного удаления.

Из всех направлений сделав основной упор на безопасность, GitLab может помочь лучше защитить вашу работу от потери данных.

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

Ограничения пропускной способности для API групп, проектов и пользователей

(SaaS: FREE, PREMIUM, ULTIMATE) Стадия цикла DevOps: Tenant Scale

Мы добавили ограничения скорости API для проектов, групп и пользователей, чтобы улучшить стабильность платформы и производительность для всех пользователей. Эти изменения появились из-за возросшего трафика API, который повлиял на работу наших сервисов.

Ограничения установлены на основе средних паттернов использования и должны обеспечить достаточную ёмкость для большинства случаев использования. Если вы превысите эти ограничения, то получите ответ «429 Too Many Requests».

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

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

Экспериментальные фичи

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

Когда эта экспериментальная фича включена, политики выполнения конвейера запускаются по регулярному расписанию с помощью настраиваемых заданий и скриптов CI/CD. В запланированных конвейерах можно внедрить сценарии соответствия, сканирование безопасности GitLab или сторонних разработчиков, а также другие пользовательские задания CI/CD. Использование конвейеров по расписанию — это ещё один инструмент, позволяющий обеспечить выполнение требований безопасности и соответствия нормативным требованиям путём выполнения заданий по ежедневному, еженедельному или ежемесячному расписанию. Запланированные конвейеры не добавляют задания в файл .gitlab-ci.yml проекта и не запускают задания из него, так что они не влияют на нижестоящие конвейеры проекта. Вместо этого можно использовать эти конвейеры для выполнения таких действий, как регулярное обращение к ветке по умолчанию для проверки зависимостей, конфигурации проекта или других требований.

Чтобы включить фичу, создайте файл policy.yml или измените существующий файл policy.yml в проекте политики безопасности и добавьте атрибут experiments. После включения можно настроить политику выполнения конвейера с расписанием, которое запускает пользовательские задания CI/CD во всех проектах, где применяется эта политика выполнения конвейера.

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

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