Правильный ответ — 1. Сравнить последний успешный и первый упавший запуск: runner, образ, переменные, кэш, зависимости и внешние сервисы.

Если код не менялся, это ещё не значит, что не менялось ничего.

Pipeline зависит от окружения: версии runner, Docker-образа в job, переменных, области действия секретов, кэша зависимостей, доступности registry, package manager, тестовой базы, API или другого внешнего сервиса.

Остальные варианты тоже могут быть полезны, но это частные гипотезы:

— откат merge имеет смысл, если есть подозрение на изменение приложения или тестов, но он не проверяет окружение сборки; — чистый кэш может помочь, если проблема в повреждённых или устаревших зависимостях, но это только один слой; — другой runner полезен для сравнения, но без фиксации условий можно получить случайный успех и не понять причину.

С чего начать системно:

Сравнить последний успешный и первый упавший запуск. Проверить, не изменился ли runner или его окружение. Уточнить, тот ли Docker-образ используется в job: tag, а при строгой проверке — digest. Проверить переменные, область действия секретов и доступы — без вывода значений в лог. Посмотреть кэш и зависимости. Отделить внутреннюю ошибку проекта от недоступности внешнего сервиса.

Практический вывод: pipeline — это не только код. Это ещё окружение, инфраструктура и внешние зависимости.

На обучении в УЦ ФОРС по Docker и DevOps такие ситуации разбираются через практику: образы, runner, переменные окружения, кэш, зависимости и диагностика нестабильных сборок.