GitLab Orbit появился в версиях 19.4.7 и 19.5.5 - условия запуска и исправленные ошибки

12 ноября 2026 года GitLab выпустила версии 19.5.5 и 19.4.7 для Community Edition и Enterprise Edition. Обновление открыло доступ к GitLab Orbit на серверах, работающих с ветками 19.4 и 19.5, и устранило ошибки, затрагивавшие просмотр исходного кода, хранение файлов и правила согласования изменений. Новых исправлений уязвимостей в этом патче GitLab не объявляла.

GitLab Orbit теперь доступен в ветках 19.4 и 19.5

GitLab Orbit связывает данные о репозиториях, запросах на слияние (merge requests), задачах, конвейерах CI/CD и обнаруженных уязвимостях. Эта информация образует граф связей, по которому разработчики и ИИ-агенты могут искать контекст проекта. Например, агент способен выяснить, какие компоненты затронет изменение кода или с какими проектами связана найденная уязвимость.

О доступности Orbit для широкого использования GitLab объявила 29 октября 2026 года. Для самостоятельно размещённых серверов поддержка изначально предусматривалась в GitLab 19.6. Выпуск 19.5.5 расширил совместимость на ветку 19.5, а параллельный патч 19.4.7 — на ветку 19.4. Разработчики называют перенос функции разовым исключением: обычно корректирующие релизы содержат исправления ошибок и уязвимостей.

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

Для запуска Orbit на своём сервере нужны отдельные компоненты

В GitLab Self-Managed функция доступна на тарифах Premium и Ultimate. Одной установки GitLab 19.5.5 недостаточно: Orbit запускается как отдельный сервис через Helm в Kubernetes. Ему нужны работающая репликация данных GitLab, хранилище ClickHouse и доступ администратора к GitLab.

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

Для GitLab Orbit 1.0.0 документация указывает конкретные совместимые версии сервера: 19.4.7, 19.5.5 и 19.6 или новее. Это ограничение влияет и на переход между ветками: при обновлении экземпляра с включённым Orbit с 19.4.7 на 19.5 нужна версия 19.5.5 или более поздняя. Более ранние выпуски 19.5 не содержат перенесённой поддержки.

В GitLab исправили зависания просмотра кода и сбой согласования IaC

Один из дефектов затрагивал проекты без артефактов LSIF — данных, используемых для навигации по исходному коду. GitLab всё равно искал связанные конвейеры при открытии файлов и различий в merge request. В проекте с десятками тысяч конвейеров для одного коммита такой поиск мог оказаться очень тяжёлым. Во внутренней проверке GitLab один запрос занимал 38,9 секунды при холодном запуске и использовал 282 МиБ памяти; у затронутого клиента страницы файлов и README возвращали ошибку 500.

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

Другой дефект касался правил согласования изменений после проверки инфраструктурного кода — Infrastructure as Code (IaC). Конфигурация политики принимала тип сканера sast_iac, но при создании правила согласования GitLab ожидал тип отчёта sast. В результате правило могло не создаться, причём ошибка фиксировалась лишь в отладочном журнале. Исправление приводит sast_iac к нужному типу отчёта. В описании исправления отдельно указано, что для ранее затронутых политик требуется повторная синхронизация resyncSecurityPolicies.

Патч затронул Google Cloud Storage и обработку JSON

При использовании Google Cloud Storage с учётными данными по умолчанию единичный тайм-аут сервера метаданных Google Compute Engine мог приводить к длительной ошибке авторизации. Библиотека запоминала, что среда якобы не работает в GCE, и последующие обращения к хранилищу получали сообщение Your credentials were not found до перезапуска процесса. В GitLab 19.5.5 добавили сброс ошибочного состояния и повторную попытку получения учётных данных.

Обновилась и Ruby-библиотека oj, которая отвечает за обработку JSON: с версии 3.17.6 до 3.17.8. В описании изменения разработчики связывают обновление с исправлениями ошибок работы с памятью и расследованием сбоев на GitLab.com. Во время одного инцидента на отдельном серверном контейнере зафиксировали около 427 аварийных завершений Ruby-процессов и примерно 16 900 ответов HTTP 502. Обновление библиотеки названо основным способом снизить вероятность повторения таких сбоев, но в сообщении о релизе не заявлено отдельного исправления уязвимости.

Обновление GitLab 19.5.5 требует миграции базы данных

Версии 19.5.5 и 19.4.7 содержат обычные миграции базы данных. На сервере с единственным узлом GitLab предупреждает о простое: приложение сможет запуститься только после завершения миграций. Для многоузловой установки компания допускает обновление без остановки сервиса при соблюдении специальной процедуры. Дополнительные post-deploy-миграции отдельно заявлены для 19.4.7.

Новая доступность Orbit на ветках 19.4 и 19.5 закреплена за конкретными корректирующими версиями. При этом последствия остальных исправлений зависят от конфигурации: проблема с GCS проявлялась при определённом способе авторизации, дефект LSIF — в проектах без таких артефактов, а сбой правил согласования — в политиках с sast_iac.