Flake bisect
Нестабильные тесты сообщаются на отдельном этапе на ботах (пример сборки).
Каждый лог теста предоставляет предварительно заполненную командную строку для запуска автоматизированного разбиения нестабильных тестов, например:
Запуск разбиения нестабильных тестов в командной строке:
bb add v8/try.triggered/v8_flako -p 'to_revision="deadbeef"' -p 'test_name="MyTest"' ...
Перед запуском разбиения нестабильных тестов в первый раз пользователи должны войти в систему с аккаунтом google.com:
bb auth-login
Затем выполните предоставленную команду, которая вернет URL сборки, запускающей разбиение нестабильных тестов (пример).
Если вам повезет, разделение укажет на подозреваемого. Если нет, вам может понадобиться прочитать дальше…
Детальное описание
Для технических деталей ознакомьтесь с трекером багов. Подход к разбиению нестабильных тестов имеет те же намерения, что и findit, но использует другую реализацию.
Как это работает?
Задача разбиения состоит из 3 фаз: калибровка, обратное и внутреннее разбиение. Во время калибровки тестирование повторяется с удвоением общего таймаута (или количества повторений), пока в одном запуске не будет обнаружено достаточно нестабильностей. Затем обратное разбиение удваивает git-диапазон, пока не будет найден ревизия без нестабильностей. Наконец, мы разбиваем диапазон между исправной ревизией и самой старой ошибочной. Заметьте, разбиение не создает новые продукты сборки, оно основано только на сборках, ранее созданных на непрерывной инфраструктуре V8.
Разбиение завершится неудачей, если…
- Нельзя достичь уверенности во время калибровки. Это типично для нестабильностей, проявляющихся один раз на миллион или для нестабильного поведения, которое видно только когда другие тесты запускаются параллельно (например, тесты с высоким потреблением памяти).
- Виновный слишком стар. Разбиение прекращается после определенного количества шагов или если старые сборки больше недоступны на сервере isolate.
- Общая задача разбиения превышает таймаут. В этом случае возможно перезапустить её с более старой известной ошибочной ревизией.
Свойства для настройки разбиения нестабильных тестов
extra_args: Дополнительные аргументы, передаваемые скрипту V8run-tests.py.- repetitions: Изначальное количество повторений теста (передается в опцию
--random-seed-stress-countскриптаrun-tests.py; не используется, если используетсяtotal_timeout_sec). timeout_sec: Параметр таймаута, передаваемый в скриптrun-tests.py.to_revision: Известная ошибочная ревизия. Это точка, с которой начнется разбиение.total_timeout_sec: Изначальный общий таймаут для одного шага разбиения. Во время калибровки это время удваивается несколько раз, если это необходимо. Установите 0, чтобы отключить и использовать вместо этого свойствоrepetitions.variant: Название варианта тестирования, передаваемое вrun-tests.py.
Свойства, которые вам не нужно менять
bisect_buildername: Имя мастера сборок, который создал сборки для разбиения.bisect_mastername: Имя мастера сборок, который создал сборки для разбиения.build_config: Конфигурация сборки, переданная в скрипт V8run-tests.py(там имя параметра —--mode, пример:ReleaseилиDebug).isolated_name: Имя изолированного файла (например:bot_default,mjsunit).swarming_dimensions: Свойства swarm, классифицирующие тип бота, на котором должны запускаться тесты. Передается как список строк, каждая в форматеname:value.test_name: Полностью квалифицированное имя теста, передаваемое вrun-tests.py. Например:mjsunit/foobar.
Советы и хитрости
Разбиение зависшего теста (например, dead lock)
Если неудачный запуск превышает таймаут, а успешный завершает работу очень быстро, полезно настроить параметр timeout_sec, чтобы разбиение не задерживалось ожиданием завершения зависших запусков. Например, если успешный завершает работу менее чем за 1 секунду, установите таймаут на что-то малое, например, 5 секунд.
Получение большей уверенности в подозреваемом
В некоторых запусках, уверенность очень низка. Например, калибровка завершается, если в одном запуске обнаружены четыре нестабильности. Во время разбиения каждый запуск с одной или более нестабильностями считается ошибочным. В таких случаях может быть полезно перезапустить задачу разбиения, установив to_revision на подозреваемого и используя большее количество повторений или больший общий таймаут, чем в оригинальной задаче, и подтвердить, что вывод остается тем же.
Обход проблем с таймаутами
В случае, если параметр общего таймаута вызывает зависание сборок, лучше всего оценить подходящее количество повторений и установить total_timeout_sec на 0.