Как узнать версию gitlab

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

GitLab предоставляет несколько независимых способов узнать номер версии: через веб-интерфейс, серверную консоль, API, а также окружение контейнеров и оркестраторов. Каждый метод применим в своей ситуации – например, при отсутствии доступа к интерфейсу администратора или при автоматизированной диагностике. Знание альтернативных вариантов позволяет получить нужные данные даже при частичной недоступности системы.

Важно учитывать различия между GitLab Community Edition и GitLab Enterprise Edition, а также формат версий вида Major.Minor.Patch. Номер релиза определяет совместимость с плагинами, требования к PostgreSQL и Redis, а также наличие конкретных изменений, указанных в release notes. В статье разобраны прикладные способы определения версии GitLab для разных сценариев эксплуатации.

Просмотр версии GitLab в веб-интерфейсе через меню Help

Веб-интерфейс GitLab позволяет узнать версию системы без доступа к серверу и административных прав. Информация отображается непосредственно в интерфейсе и подходит для быстрой проверки при работе с репозиториями, issues или CI/CD.

Для получения данных выполните следующие действия:

1. Авторизуйтесь в GitLab под любой учетной записью.
2. В правом верхнем углу нажмите на иконку знака вопроса ?.
3. В выпадающем меню выберите пункт Help или Help & feedback.
4. Откройте раздел Help, где в нижней части страницы отображается версия GitLab.

Номер версии указывается в формате Major.Minor.Patch, например 16.7.2, и сопровождается указанием редакции – CE или EE. Эти данные используются для сопоставления с официальной документацией и release notes.

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

Определение версии GitLab на странице входа в систему

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

После загрузки страницы входа обратите внимание на подвал интерфейса. Там указывается номер версии в формате Major.Minor.Patch и редакция продукта – Community Edition или Enterprise Edition. Пример отображения: GitLab EE 16.6.1.

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

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

Получение версии GitLab с помощью команды gitlab-rake

Инструмент gitlab-rake предоставляет доступ к внутренним данным GitLab и позволяет определить версию напрямую на сервере. Этот способ применяется, когда требуется получить сведения из системы без опоры на браузер или при ограниченном доступе к интерфейсу.

Подключитесь к серверу по SSH и выполните команду в среде Omnibus-установки GitLab:

sudo gitlab-rake gitlab:env:info

В результате выполнения будет выведен подробный отчет об окружении. Строка GitLab version содержит полный номер версии с указанием редакции и patch-уровня, например 16.5.3-ee. Эти данные используют для сопоставления с требованиями обновлений и проверок совместимости.

Проверка версии GitLab через файл VERSION на сервере

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

В стандартной Omnibus-установке файл располагается по пути /opt/gitlab/embedded/service/gitlab-rails/VERSION. Для просмотра содержимого достаточно подключиться к серверу по SSH и выполнить чтение файла с помощью любой утилиты командной строки.

Внутри файла указывается версия в формате Major.Minor.Patch, например 16.4.1. Значение соответствует фактически установленному коду приложения и не зависит от состояния базы данных или фоновых процессов.

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

Узнавание версии GitLab в контейнере Docker

При запуске GitLab в Docker версия определяется на уровне контейнера и может отличаться от данных в веб-интерфейсе, если образ был обновлён без пересоздания контейнера. Проверка выполняется через Docker CLI и не требует доступа к браузеру.

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

Наиболее надёжным считается запуск команды gitlab-rake gitlab:env:info через docker exec, так как она отражает реально используемую версию приложения. Проверка только по тегу образа допустима для инвентаризации, но не подходит для диагностики проблем после обновлений.

При сопровождении нескольких контейнеров рекомендуется фиксировать версию GitLab вместе с digest образа, чтобы избежать расхождений при повторном развёртывании окружения.

Определение версии GitLab в Kubernetes через pod

При развертывании GitLab в Kubernetes версия определяется на уровне pod и зависит от используемого контейнерного образа. Проверка выполняется через kubectl и подходит для кластеров, где веб-интерфейс GitLab недоступен или требуется оперативная диагностика.

Для получения версии сначала необходимо определить pod, в котором запущен основной компонент GitLab. Обычно это pod с именем, содержащим webservice или gitlab, в зависимости от Helm-чарта и конфигурации.

1. Получите список pod в нужном namespace с помощью kubectl.
2. Выберите pod GitLab с запущенным Rails-приложением.
3. Подключитесь к контейнеру через exec.

После подключения выполните команду получения информации об окружении GitLab:

gitlab-rake gitlab:env:info

Альтернативно можно проверить версию по тегу образа:

• описание pod через kubectl с указанием image;
• значение тега, например 16.7.1-ee, используется для быстрой идентификации.

Для точной диагностики предпочтительно выполнять команды внутри pod, так как они учитывают реальные обновления и изменения, применённые в работающем окружении Kubernetes.

Проверка версии GitLab через API

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

Для запроса используется endpoint /api/v4/version. Аутентификация не требуется, если доступ к API не ограничен на уровне конфигурации. Запрос возвращает данные в формате JSON.

В ответе присутствуют поля version и revision. Значение version содержит номер релиза в формате Major.Minor.Patch, например 16.7.0, а revision указывает конкретный коммит сборки.

При использовании балансировщиков или нескольких узлов запрос рекомендуется выполнять к каждому endpoint отдельно, так как версии могут отличаться во время поэтапного обновления. Это позволяет выявить несинхронизированные ноды.

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

Вопрос-ответ:

Можно ли узнать версию GitLab без входа под учетной записью?

Да, это возможно. Версия часто отображается в нижней части страницы входа в систему. Если подвал интерфейса не скрыт настройками или брендингом, там указывается номер релиза и редакция GitLab. Также без авторизации доступен API-эндпоинт /api/v4/version, который возвращает данные в формате JSON.

Почему версия GitLab в интерфейсе отличается от тега Docker-образа?

Такое расхождение возникает, если контейнер был запущен из одного образа, а затем обновлён без пересоздания. Тег образа показывает ожидаемую версию, а фактическая версия определяется кодом, который сейчас выполняется. Для проверки текущего состояния следует выполнять gitlab-rake gitlab:env:info внутри контейнера.

Как узнать версию GitLab, если веб-интерфейс не открывается?

В этом случае используется доступ к серверу или контейнеру. Через SSH можно запустить gitlab-rake gitlab:env:info или прочитать файл VERSION в каталоге GitLab. Оба способа работают независимо от состояния браузерного интерфейса.

Какая версия считается корректной при поэтапном обновлении нескольких нод?

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

Нужно ли учитывать patch-номер версии при диагностике ошибок?

Да. Исправления часто выпускаются в рамках одного minor-релиза и отличаются только patch-уровнем. Два инстанса с одинаковыми major и minor, но разными patch-номерами, могут вести себя по-разному при одинаковых сценариях использования.