Dev48
ЯЗЫК
  • О нас
  • Услуги
  • Индустрии
  • Технологии
  • Статьи
  • Контакты
Забронировать звонок
    Главная/Статьи/Primechaniya k vypusku gitlab 191
Dev48

© 2026 · All rights reserved.

Примечания к выпуску GitLab 19.1

Фото: 3534679 (Pixabay) — https://pixabay.com/photos/yoga-calm-release-stretching-2662234/

Примечания к выпуску GitLab 19.1

Источник: GitLab Docs

Выпущен GitLab 19.1 с функцией обнаружения ложноположительных срабатываний секретов с помощью GitLab Duo.

25 сентября 2026 г.

18 июня 2026 года состоялся релиз GitLab 19.1, включающий следующие функции.

Мы рады отметить Pishel65, участника 3-го уровня, у которого 19 объединенных MR и еще 9 открытых с момента присоединения в октябре 2025 года.

Основные функции

Обнаружение ложноположительных срабатываний секретов с помощью GitLab Duo

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

Функция обнаружения ложноположительных срабатываний секретов с помощью платформы GitLab Duo Agent теперь общедоступна.

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

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

Основные функции включают:

  • Автоматический анализ: выполняется после каждого сканирования безопасности без ручного запуска.
  • Ручной запуск: запуск обнаружения ложноположительных срабатываний для отдельных уязвимостей на странице сведений об уязвимости для анализа по требованию.
  • Фокус на важных находках: анализ только критических уязвимостей и уязвимостей высокого уровня серьезности для максимального улучшения соотношения сигнал/шум.
  • Контекстное обоснование ИИ: каждая оценка включает объяснение того, почему находка, вероятно, является истинно положительной, основанное на контексте кода и характеристиках уязвимости.
  • Оценка достоверности: каждое обнаружение включает оценку достоверности, чтобы помочь командам расставить приоритеты проверки на основе уверенности модели.
  • Бесшовная интеграция рабочего процесса: результаты отображаются непосредственно в отчете об уязвимостях вместе с существующей информацией о серьезности, статусе и исправлении.

Мы приветствуем ваши отзывы в задаче 592861.

Режим постоянной доступности для GitLab Duo

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

Администраторы теперь могут настроить GitLab Duo так, чтобы он был всегда включен для всех проектов во всем экземпляре или группе верхнего уровня. Когда для GitLab Duo установлено значение «всегда включен», владельцы групп, подгрупп и проектов не могут отключить GitLab Duo, что дает предприятиям централизованное управление ИИ для обеспечения соответствия требованиям и работы в регулируемых средах.

Эта новая настройка симметрична существующей настройке «всегда выключен», устраняя пробел, при котором GitLab Duo можно было заблокировать в выключенном состоянии, но нельзя было заблокировать во включенном. Эта новая настройка особенно ценна для организаций с автономными подразделениями или дочерними компаниями, которым необходимо гарантировать согласованное использование инструментов ИИ во всем бизнесе.

Чтобы установить GitLab Duo в режим «всегда включен», перейдите в настройки GitLab Duo экземпляра или группы верхнего уровня и установите доступность GitLab Duo на «Всегда включен».

Автоматическое назначение владельцев кода (Code Owners) в качестве рецензентов

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Ранее вам нужно было вручную выбирать рецензентов для каждого запроса на слияние (merge request), даже если файл CODEOWNERS уже определял, кто должен проверять каждый файл.

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

Чтобы включить автоматическое назначение рецензентов, перейдите в Settings > Merge requests > Automatic reviewer assignment и выберите Automatically assign all code owners as reviewers.

Шаблоны фреймворков соответствия (бета-версия)

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

Теперь вы можете создавать фреймворки соответствия из предопределенных шаблонов.

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

Теперь, когда вы создаете новый фреймворк в Центре соответствия (Compliance center), вы можете:

  • Выбрать «Создать из шаблона» (Create from template), чтобы начать с предварительно настроенного фреймворка с уже существующими требованиями и контролями.
  • Предварительно просмотреть каждый шаблон, настроить имя, описание и цвет, а затем применить его к своей группе за один шаг.

Доступно 19 шаблонов, включая ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX и другие.

Улучшенное покрытие обнаружения секретов для конвейеров веток функций

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

В версиях GitLab до 19.1 вы не могли доверять конвейеру ветки функций (feature branch pipeline) в обнаружении каждого секрета в вашей ветке. Новая ветка сканировала только последний коммит. Существующая ветка сканировала только ваш самый последний пуш. Учетные данные, утечка которых произошла в более раннем коммите, могли оставаться необнаруженными, попадая в общие ветки или в продакшн до того, как их помечали.

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

Ограждения для утверждения инструментов для агентов GitLab Duo (бета-версия)

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

Администраторы теперь могут настраивать политики утверждения на уровне инструментов для агентов GitLab Duo, ограничивая чувствительные действия утверждением человека в момент выполнения.

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

  • Разрешить (выполнять без уведомления).
  • Запросить (требовать одобрения человека).
  • Запретить (блокировать полностью).

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

Этот бета-релиз включает Agentic Chat, IDE и потоки, а также создает события аудита для каждого решения об утверждении.

Agentic Core

Элементы управления для пользовательских и внешних функций ИИ

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Администраторы и владельцы групп верхнего уровня теперь могут контролировать, какие агенты и потоки ИИ доступны в их организации. Они могут:

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

Валидация YAML для пользовательских потоков

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

AI Catalog теперь проверяет конфигурацию вашего пользовательского потока (custom flow) перед его сохранением или запуском.

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

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

Одобрение инструментов на основе шаблонов для Agentic Chat

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Эта функция была удалена 10 июля 2026 года.

Ранее, когда Agentic Chat запрашивал одобрение на вызов инструмента, вы могли одобрить его один раз или одобрить вызов инструмента с данными аргументами на оставшуюся часть сессии. Другие аргументы требовали дополнительного одобрения.

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

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

Одобрения на основе шаблонов доступны для Agentic Chat в интерфейсе GitLab, GitLab Duo CLI, GitLab для VS Code и плагине GitLab Duo для IDE JetBrains.

Автоматическое рецензирование кода для новых клиентов GitLab

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com
  • Ссылки: Документация · Связанная задача

Автоматические проверки в Code Review Flow теперь включены по умолчанию для новых клиентов пробной версии GitLab Duo на GitLab.com, поэтому вы можете начать получать отзывы на основе ИИ для своих merge requests с первого дня — без какой-либо ручной настройки.

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

Проверки готовности базовых потоков (Foundational flows)

  • Уровень: Premium, Ultimate
  • Предложение: GitLab Self-Managed, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

Проверки работоспособности GitLab Duo теперь включают проверки готовности базовых потоков, которые подтверждают:

  • Настройка выполнения потоков на уровне экземпляра включена.
  • Настройка базовых потоков на уровне экземпляра включена.
  • Зарегистрирован и подключен как минимум один активный экземпляр раннера с тегом gitlab--duo, использующий Docker-совместимый исполнитель.

Модели GPT для Code Review Flow

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

В предыдущих версиях GitLab Code Review Flow поддерживал только модели Anthropic Claude. Команды, которые не могли использовать модели Anthropic из-за договорных, политических или закупочных ограничений, не имели возможности запускать Code Review Flow.

Теперь вы можете выбрать GPT-5.2 или GPT-5.3 Codex в качестве модели для Code Review Flow. Владельцы групп верхнего уровня могут переключить модель для Agentic Code Review в разделе Settings > GitLab Duo > Configure features, в подразделе GitLab Duo Agent Platform. Модели GPT размещаются через GitLab AI Gateway, поэтому дополнительная настройка не требуется.

Обе модели прошли сравнительное тестирование на наборе данных GitLab Duo для проверки кода, при этом качество проверки сопоставимо с моделью по умолчанию Claude Sonnet 4.6 Vertex. Результаты см. в сравнительном анализе проверки кода.

Список разрешенных моделей (allowlist)

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Для GitLab Duo Agentic Chat теперь можно настроить список разрешенных моделей и установить значение по умолчанию для всей организации, если вы:

  • На GitLab.com: владелец группы верхнего уровня.
  • На GitLab Self-Managed: администратор экземпляра.

Это дает организациям контроль над тем, какие модели могут выбирать пользователи при использовании Agentic Chat.

Новые триггеры событий для потоков и внешних агентов

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

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

Теперь вы можете настроить триггеры для четырех дополнительных событий:

  • Merge request готов: пользователь помечает черновик merge request как готовый к проверке. Ранее выпущенный за флагом функции, этот триггер события теперь общедоступен.
  • Конфликт кода в merge request: merge request больше не может быть объединен из-за конфликта кода.
  • Merge request одобрен: merge request получил все необходимые одобрения.
  • Рабочий элемент создан: пользователь создает рабочий элемент в проекте.

Чтобы настроить триггер, перейдите в AI > Triggers в вашем проекте или выберите его при включении потока.

Единый DevOps и безопасность

Устранение пробелов в покрытии с помощью мастера включения сканеров (Scanner Enablement Wizard)

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

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

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

Пользовательское время жизни для токенов доступа OAuth

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

По умолчанию токены доступа OAuth в GitLab истекают через два часа. В GitLab 19.1 администраторы экземпляров на GitLab Self-Managed и GitLab Dedicated могут установить пользовательское время жизни для новых токенов доступа OAuth. Вы можете настроить любое значение от 300 до 7200 секунд. Это помогает обеспечить использование токенов с коротким сроком действия для критически важных с точки зрения безопасности интеграций OAuth, включая клиенты MCP, не меняя поведение существующих токенов.

Реакции эмодзи на страницах вики

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

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

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

Политики выполнения запланированных конвейеров (бета)

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Политики запланированного выполнения конвейеров (pipeline) теперь доступны в бета-версии и больше не требуют включения экспериментального флага. Вы можете принудительно запускать пользовательские CI/CD-задания ежедневно, еженедельно или ежемесячно во всех своих проектах, независимо от активности коммитов. Используйте запланированные политики для запуска скриптов соответствия требованиям, сканирования безопасности или проверки зависимостей в репозиториях, где код может меняться нерегулярно.

Запланированные политики теперь обеспечивают приоритет переменных так же, как и обычные политики выполнения конвейеров. Каждый проект политик безопасности поддерживает до пяти запланированных политик, и GitLab автоматически отменяет запущенные конвейеры при отключении или удалении политики. Настраивайте расписания в YAML или через интерфейс с поддержкой часовых поясов, распределением временных окон, выбором веток и функцией откладывания (snooze).

Роль «Менеджер по безопасности» (Security Manager) теперь общедоступна

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

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

Пользователи с ролью «Менеджер по безопасности» имеют следующий доступ:

  • Управление уязвимостями: просмотр, сортировка и управление уязвимостями в группах и проектах.
  • Политики безопасности: просмотр и управление политиками безопасности на уровне группы, а также внесение правок в YAML-файлы политик на уровне проекта.
  • Инвентаризация безопасности: просмотр охвата сканерами всех проектов в группе.
  • Профили конфигурации безопасности: просмотр профилей конфигурации безопасности для групп и проектов.
  • Инструменты соответствия требованиям: просмотр и управление событиями аудита, центром соответствия, фреймворками соответствия, отчетами о статусе соответствия и списками зависимостей как на уровне группы, так и на уровне проекта.
  • Защита от отправки секретов (Secret push protection): включение защиты от отправки секретов для группы и проекта.
  • DAST по запросу: создание и запуск сканирований DAST по запросу для проекта.
  • Видимость раннеров: просмотр раннеров для группы и проекта.

Чтобы начать работу, перейдите в группу и выберите Manage > Members, чтобы пригласить пользователей и назначить им роль «Менеджер по безопасности».

Использование результатов сторонних сканеров в GitLab

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Теперь вы можете использовать результаты сканирования безопасности от любого сканера, совместимого с SARIF 2.1.0, в системе управления уязвимостями GitLab.

Определите CI/CD-задание, которое запускает ваш сканер и создает артефакт SARIF. GitLab анализирует, проверяет и импортирует эти результаты в ваши рабочие процессы безопасности. Результаты отображаются наряду с данными собственных сканеров GitLab на вкладке безопасности конвейера, в отчете об уязвимостях, на панели мониторинга безопасности, в виджете безопасности запроса на слияние (merge request) и в политиках безопасности. Эта функция дает командам безопасности единое консолидированное представление об уязвимостях, независимо от того, какой инструмент их обнаружил.

GitLab присваивает каждой находке тип отчета на основе ее идентификаторов, распределяя результаты по таким категориям, как SAST, сканирование зависимостей и обнаружение секретов. Поддерживаемые сканеры включают Semgrep и Checkmarx для SAST, Trivy и Snyk для сканирования зависимостей и контейнеров, а также Gitleaks для обнаружения секретов.

Страницы Wiki в списке недавно просмотренных элементов

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

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

На главной странице GitLab виджет быстрого доступа (Quick access) перечисляет недавно просмотренные страницы Wiki проектов и групп наряду с задачами (issues), запросами на слияние и эпиками. GitLab автоматически удаляет страницы, которые были удалены или к которым у вас больше нет доступа.

Аналитика CI/CD теперь показывает точные показатели конвейеров

  • Уровень: Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

В предыдущих версиях GitLab показатели частоты сбоев и успеха на странице аналитики CI/CD (<project>/-/pipelines/charts) включали в расчеты отмененные и пропущенные конвейеры. Из-за этого оба показателя выглядели ниже ожидаемых. Например, в gitlab-org/gitlab сумма этих двух показателей составляла всего 98% вместо примерно 100%.

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

Более понятные метки в деталях уязвимостей, соответствующие отраслевым стандартам безопасности

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

В GitLab 19.1 страница деталей результатов уязвимостей использует последовательную, описательную терминологию, соответствующую отраслевым стандартам безопасности для результатов сканирования:

  • Scanner теперь называется Detected by
  • EPSS теперь называется Exploit Probability (EPSS)
  • Has Known Exploit (KEV) теперь называется Known Exploited (CISA KEV)
  • Reachable теперь называется Reachability
  • Image теперь называется Container Image (Container Scanning)
  • Location теперь называется Affected Location
  • URL теперь называется Affected Endpoint (DAST, API fuzzing)
  • Method теперь называется HTTP Method (DAST, API fuzzing)
  • Solution теперь называется Remediation Guidance
  • Links теперь называется References

События аудита Git-операций для всех типов субъектов

  • Уровень: Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

В GitLab 18.10 журналы аудита начали фиксировать конкретную Git-операцию (clone, pull, fetch или push), выполняемую пользователями.

В GitLab 19.1 это распространилось на все типы субъектов, включая раннеры, использующие токены развертывания (deploy tokens), и пользователей SSH-сертификатов. Журналы аудита теперь отражают полную картину всей Git-активности в ваших репозиториях, независимо от того, кто или что ее инициировало.

GitLab Runner 19.1

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government
  • Ссылки: Документация · Связанная задача

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

Что нового

  • Добавлен настраиваемый таймаут get_sources в конфигурацию раннера

Исправления ошибок

  • Конкретное выполнение (FF_CONCRETE) расходится с абстрактной оболочкой в нескольких областях поведения
  • Загрузки Bundle URI завершаются с ошибкой из-за недостаточных возможностей при включенных FF_USE_GIT_PROACTIVE_AUTH и FF_USE_GIT_BUNDLE_URIS
  • Предотвращение дампа скрипта при отмене задания через интерфейс из-за состояния гонки

Список всех изменений находится в CHANGELOG GitLab Runner.

Встроенное отображение blame в средстве просмотра файлов (blob viewer)

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Ранее для просмотра информации blame требовался переход на отдельную страницу, что прерывало рабочий процесс при проверке кода.

Теперь вы можете переключать отображение информации blame непосредственно в окне просмотра файла. Каждая строка показывает, кто внес последние изменения, а при наведении курсора появляется всплывающее окно с подробностями коммита. Выберите «View blame prior to this change» (Просмотреть blame до этого изменения), чтобы отследить историю дальше, или выберите «Ignore specific revisions» (Игнорировать определенные ревизии), чтобы исключить конкретные коммиты из представления blame.

Обновленный список коммитов репозитория

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

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

Обновленный список коммитов включает:

  • Фильтрацию и поиск коммитов по автору, сообщению коммита или диапазону дат.
  • Фильтрацию списка по ревизии Git, например, по ветке, тегу или SHA коммита.
  • Группировку коммитов по дням для более удобного просмотра.
  • Улучшенную производительность и пагинацию для больших репозиториев.

Стековые merge requests в интерфейсе

  • Уровень: Free, Premium, Ultimate
  • Предложение: GitLab.com, GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Ранее, когда вы разбивали большое изменение на несколько небольших merge requests, которые зависят друг от друга, интерфейс не давал сигнала об их связи. Авторам и рецензентам приходилось отслеживать последовательность вручную.

Теперь GitLab автоматически обнаруживает стековые merge requests и отображает их в заголовке merge request. Merge request присоединяется к стеку, когда он нацелен на исходную ветку другого открытого merge request, или когда другой открытый merge request нацелен на его исходную ветку. Элемент управления стеком рядом с исходной веткой показывает текущую позицию (например, 1 из 2) и позволяет перейти к любому другому merge request в стеке.

Чтобы создавать стековые merge requests из командной строки, используйте stacked diffs в GitLab CLI.

Потоковая передача событий аудита ИИ во внешние пункты назначения (бета-версия)

  • Уровень: Ultimate
  • Предложение: GitLab Self-Managed, GitLab Dedicated
  • Ссылки: Документация · Связанная задача

Теперь вы можете передавать события аудита ИИ во внешние пункты назначения через инфраструктуру потоковой передачи событий аудита GitLab, что дает командам безопасности и комплаенса возможность отслеживать взаимодействие с LLM и ИИ в режиме реального времени.

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

← Все статьи