В CI настроены повторы упавших тестов. Определите главный риск такой настройки для достоверности результата.
ci:
run: test-suite
retry_failed_tests: 3
merge_allowed_if: passed_on_last_attempt
Главный риск — нестабильный или дефектный тест может стать зелёным после повтора, поэтому CI перестаёт надёжно сигнализировать о проблемах. Условие passed_on_last_attempt маскирует сам факт сбоя и позволяет сломанный код попасть дальше по процессу.
Повторы допустимы как временный диагностический механизм или защита от редких внешних сбоев, но не как критерий успешности теста. Каждый первый сбой должен сохраняться, классифицироваться и попадать в метрики.
Повторы появились как практическая реакция на нестабильность инфраструктуры: сетевые ошибки, временную недоступность зависимостей, задержки окружения и дефекты синхронизации. В распределённых CI-системах единичный технический сбой действительно не всегда означает ошибку продукта.
Проблема возникла, когда повтор стали использовать не для диагностики, а для получения зелёного пайплайна. Это превратило механизм снижения шума в механизм сокрытия сигналов.
В приведённой конфигурации тест, упавший трижды или один раз, получает одинаковый итоговый статус, если последняя попытка успешна. Команда не видит, что тест уже нарушил ожидаемое поведение, а статистика успешных сборок становится завышенной.
Последствия зависят от типа ошибки: настоящий регресс может быть принят, нестабильность будет накапливаться, а расследование станет сложнее из-за потери первого стека, лога и состояния окружения. Особенно опасны повторы для тестов, проверяющих необратимые операции, отправку событий или изменение данных.
Нужно разделить результат попытки и окончательный статус задания. Первая неудача должна сохраняться независимо от того, прошёл ли тест при повторе. Повтор можно разрешить, но успешный повтор должен помечать тест как нестабильный, а не стирать исходный сбой.
Практичная политика выглядит так:
Важно повторять именно минимальную единицу, которая может быть безопасно повторена. Повтор всего набора увеличивает время CI и может скрыть взаимное влияние тестов. Повтор теста с сохранённым состоянием может дать ложный результат: предыдущая попытка уже изменила базу данных, очередь или внешний ресурс.
Автоматические повторы не заменяют поиск причины. Для анализа нужны логи каждой попытки, окружение, версия сборки, длительность и частота первичных сбоев. Метрикой качества следует считать не только финальный процент успешных сборок, но и долю тестов, прошедших с первой попытки.
После миграции CI команда заметила, что сборки стали почти всегда зелёными, хотя UI-тесты периодически падали по тайм-ауту. Рассматривались три варианта: отключить повторы полностью, оставить три повтора без изменений или сохранять первый сбой и повторять только тесты с признаками инфраструктурной ошибки.
Полное отключение давало прозрачный сигнал, но временно увеличивало шум из-за известной проблемы с окружением. Три повтора без изменений сохраняли скорость разблокировки, но скрывали регрессии. Выбрали третий вариант: первый сбой сохранялся как артефакт, повтор был ограничен одним запуском, а нестабильные тесты публиковались в отдельном отчёте и имели владельцев.
В результате команда перестала считать случайный успешный повтор чистым прохождением. Пайплайн остался пригодным для работы с временными сбоями, но ухудшение стабильности стало измеримым и заметным.
Нет, это зависит от цели отчёта. Для разблокировки некритичного этапа такой результат можно принять как технически успешный, но в отчёте он должен иметь статус нестабильного прохождения. Иначе метрика качества тестов и доверие к CI будут искажены.
Повтор может выполняться уже в изменённом состоянии. Например, первая попытка создала запись, отправила сообщение или оставила блокировку, поэтому вторая проверяет не исходный сценарий и способна пройти по другой причине. Без изоляции данных и очистки состояния повтор не подтверждает воспроизводимость результата.
Одного признака обычно недостаточно. Нужны классификация ошибок, анализ кодов ответа и логов инфраструктуры, сравнение с другими тестами и история повторяемости. Автоматическое правило может разрешать ограниченный повтор только для узкого набора подтверждённых технических ошибок, но спорные случаи должны оставаться видимыми для ручного анализа.