Self-hosted runner vs shared runner: что меняется в логах CI

Shared runner удобен: инфраструктуру обслуживает платформа. Self-hosted runner гибче: можно поставить свои tools, дать доступ к внутренней сети и ускорить сборки. Но в логах это два разных мира.

Если вы только начинаете администрировать runner'ы, важно не списывать каждое падение на код. Иногда сломался именно runner.

Коротко: чем runner отличается от job

Job — набор команд из CI-конфига. Runner — место, где эти команды выполняются. Один и тот же job может вести себя по-разному на GitHub-hosted, GitLab shared или self-hosted runner.

Что ломается на self-hosted чаще

сеть до registry или внутреннего сервиса;
заполненный диск;
старые версии Docker/Node/Java;
права пользователя runner;
оставшиеся файлы от прошлых job;
локальный cache, который никто не чистит;
доступ к secret manager или Kubernetes cluster.

Что ломается на shared чаще

нет доступа к внутренней сети;
слишком короткий timeout;
ограничения на privileged containers;
медленный cold start;
несовместимая версия образа;
rate limit внешнего registry.

Как читать лог

Смотрите не только последнюю ошибку. Если npm test упал после ENOSPC, это не проблема тестов, а диск. Если docker pull не может достучаться до registry, приложение ещё не запускалось. Если ошибка появляется только на одном self-hosted runner, сравните host state.

Где тут Exlogare

Exlogare полезен, когда нужно быстро отделить code regression от окружения. RCA может подсказать: «похоже на disk full на self-hosted runner» или «registry недоступен из shared runner». Для универсального подключения подойдёт generic ingest, а для GitLab/GitHub — соответствующие интеграции.

Чеклист

Узнайте тип runner для failed job.
Проверьте disk, network, registry.
Сравните версии tools.
Посмотрите, повторяется ли ошибка на другом runner.
Отделите infra failure от тестового падения.
Не храните raw logs с секретами дольше, чем нужно.