Недавно столкнулся с довольно раздражающей ситуацией в GitLab. Запушил код, а вместо привычного зеленого пайплайна получил красное сообщение: «Identity verification is required in order to run CI jobs». Сначала подумал — ну вот, опять эти платформы ужесточают требования к бесплатным аккаунтам.
Что произошло
История началась банально. Работаю над проектом, делаю коммит с описанием «Remove obsolete HTML files related to techniques, unauthorized tests, testing…». Обычное дело — чистка старого кода. Но GitLab решил, что мой аккаунт недостаточно «доверенный» для запуска CI/CD процессов.
Первая мысль была логичной: пройти эту самую верификацию личности. Но тут возникла проблема — не хотелось светить банковской картой или привязывать личные данные к рабочему проекту. Да и времени на бюрократию не было.
Стандартный подход не работал
В интернете все советы сводились к одному: «Пройдите верификацию, привяжите карту, подтвердите телефон». Логично, но не всегда применимо. Особенно когда работаешь с корпоративными проектами или просто не хочешь раскрывать лишние данные.
Вспомнил, что у меня уже настроен собственный GitLab Runner на сервере. Он крутится в Docker’е, работает стабильно, ресурсов хватает. Почему бы не попробовать отключить встроенные раннеры GitLab и использовать только свой?
Неожиданное решение
Зашел в настройки проекта, нашел раздел CI/CD → Runners. Там есть переключатель «Enable instance runners for this project». По умолчанию он включен — это означает, что GitLab будет пытаться использовать свои встроенные раннеры для выполнения джобов.
Отключил этот переключатель. И… о чудо! Пайплайн тут же запустился на моем собственном раннере, минуя все проверки верификации.
Честно говоря, сам не ожидал такого результата. Логика подсказывала, что требование верификации должно применяться ко всем пайплайнам независимо от типа раннера. Но видимо, GitLab проверяет статус аккаунта только при попытке использовать их собственные вычислительные ресурсы.
Почему это работает
Подумав об этом, понял логику GitLab. Требование верификации — это способ защиты от злоупотребления бесплатными ресурсами. Если вы используете свои собственные мощности, то платформе нет смысла вас ограничивать. Вы не тратите их деньги на электричество и железо.
Это похоже на ситуацию в спортзале: если приносите свои гантели, никто не спрашивает справку о доходах. А вот для использования тренажеров зала могут потребовать документы.
Как настроить собственный раннер (кратко)
Если у вас еще нет своего раннера, вот быстрый способ его поднять:
- Создаете новый раннер в настройках проекта GitLab
- Копируете токен регистрации
- Запускаете на своем сервере:
docker run -d --name gitlab-runner --restart always \
-v /var/run/docker.sock:/var/run/docker.sock \
-v gitlab-runner-config:/etc/gitlab-runner \
gitlab/gitlab-runner:latest
- Регистрируете раннер с полученным токеном
- Отключаете instance runners в настройках проекта
Весь процесс занимает минут 15-20, если сервер уже есть.
Подводные камни
Конечно, у этого решения есть нюансы. Собственный раннер — это дополнительная ответственность. Нужно следить за его работоспособностью, обновлениями, безопасностью. Если сервер упадет — пайплайны встанут.
Плюс расходы на хостинг, хотя для небольших проектов подойдет даже самый дешевый VPS за 5-10 долларов в месяц.
Иногда решение проблемы лежит не в том направлении, куда указывают все мануалы. GitLab хочет верификацию для использования своих ресурсов? Окей, не будем их использовать. Есть свой сервер — используем его.
Этот способ особенно актуален для разработчиков, которые уже имеют собственную инфраструктуру или работают в командах с корпоративными серверами. Зачем проходить лишние проверки, если можно обойтись своими силами?
Правда, стоит помнить — это скорее обходной путь, чем полноценное решение. Если планируете серьезно работать с GitLab, верификацию все равно лучше пройти. Но для быстрого решения текущей задачи — вполне рабочий вариант.