GitLab CI: job завис в pending — как проверить Runner и теги

После push появился pipeline, а тесты несколько минут стоят в pending. Перезапуск job создаёт ещё одну попытку с тем же результатом. В этот момент полезно выяснить, получил ли исполнитель работу: если журнал ещё не начинается строкой Running with gitlab-runner, проверять тестовый скрипт рано. GitLab должен сначала найти подходящий Runner и свободную возможность выполнения.

Runner — зарегистрированный исполнитель, который запрашивает задания у GitLab. Одного запущенного процесса на сервере недостаточно: конкретному проекту должен быть доступен Runner, которому разрешена именно эта работа. Разберём пример проекта с Linux-контейнерами и отдельным исполнителем для публикации релизов.

Сначала найдём того, кто вообще может взять job

Откройте страницу зависшей job и сохраните её сообщение о причине ожидания. Затем в настройках проекта CI/CD раскройте Runners. Найдите доступных проекту исполнителей и посмотрите состояние, паузу, теги и время последнего контакта. Если доступного исполнителя нет, правка YAML не восстановит связь: потребуется включить подходящий project, group или instance runner либо зарегистрировать новый.

Если Runner отображается online, это ещё не означает совпадение требований. Например, у него теги linux и docker, а задача требует linux, docker и release. Для назначения нужны все теги job, а не один из них. Слово docker здесь служит меткой, оно само по себе не устанавливает Docker и не выбирает executor.

probe:
  image: alpine:3.21
  tags:
    - linux
    - docker
  script:
    - uname -s
    - cat /etc/os-release

Это полный минимальный файл .gitlab-ci.yml для диагностической ветки. Он рассчитан на доступный Linux Runner с Docker executor и обоими указанными тегами. После назначения первая команда должна показать Linux, а файл os-release — систему внутри образа Alpine. Так мы отделяем назначение задания от проблем приложения. На Shell executor ключ image не создаёт контейнер: команды выполняются в окружении машины Runner.

Почему удаление tags не всегда помогает

У исполнителя отдельно настраивается Run untagged jobs. Если этот параметр выключен, job без tags ему не подходит. Получается частая диагностическая ловушка: сначала набор тегов был слишком строгим, затем его удалили целиком, но исполнитель по-прежнему не берёт работу. Сопоставьте оба случая с правилами выбора Runner и настройкой конкретного исполнителя.

Лучше договориться о небольшом наборе меток возможностей. Например, linux обозначает ОС, docker — согласованный контейнерный executor, release — доступ к релизному окружению. Добавляйте release только туда, где этот доступ требуется. Случайное добавление метки ко всем тестам направит всю нагрузку в узкую очередь деплоя.

Одинаковые теги, разные ветки

Следующий вопрос возникает, когда main проходит, а feature-ветка стоит. Проверьте Protected у Runner и protected-статус ветки или тега. Исполнитель, которому доверили релизные секреты, может быть ограничен защищёнными refs. Для merge request pipelines действуют дополнительные условия доступа к защищённым ресурсам; нельзя делать вывод только из того, что target branch называется main.

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

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

Когда доступ, теги и защита совпали, посмотрите, выполняет ли Runner другие задания. Одна очередь обслуживается конечным числом рабочих слотов. Сравните длительность текущих jobs с моментом появления pending: если новые работы начинают исполняться после завершения предыдущих, механизм назначения работает, а задержка связана с ёмкостью.

Администратору полезны ограничения concurrent и limit в конфигурации Runner и его журнал запросов к GitLab. Значения не стоит увеличивать вслепую: контейнерные сборки потребляют память и диск, а Shell jobs могут мешать друг другу в общем окружении. Сначала определите, сколько параллельных работ выдерживает машина и какой класс задач заполнил очередь.

Если же online-исполнитель свободен, но не получает подходящую работу, сопоставьте время последнего контакта с журналом его сервиса: ошибки сети, TLS или авторизации требуют исправления соединения. Сохранённые ID job и Runner позволят обсуждать одну конкретную пару, вместо общего сообщения «CI завис».

После исправления повторите диагностическую job, затем исходные тесты. Если probe исполняется, а основная задача уже падает в script, очередь пройдена: дальше разбирают зависимости, команды и окружение. Это другой этап выполнения, и в его журнале уже есть факты для следующего решения.

Ещё по теме

• Cache и artifacts в GitLab CI: как передать результат сборки следующему job
• GitLab CI запускает два pipeline на один push: разбираем workflow и rules

Продолжить изучение

Хотите собрать проверяемый путь от коммита до релиза? Jobs, runners, артефакты и деплой — темы программы «GitLab CI/CD: автоматизация сборки и деплоя».