Як автоматизувати пошук коміту, що зламав код, через git bisect run?

Ручний git bisect вимагає на кожному кроці перевірити код і сказати good чи bad. git bisect run робить це сам: на кожному кроці запускає скрипт і читає його код завершення.

git bisect start HEAD v2.3.0      # погана ревізія, потім добра
git bisect run php artisan test --compact --filter=VacancyExportTest
git bisect reset

На 1000 комітах це близько 10 запусків тесту замість ручного пошуку.

Як Git трактує код завершення:

Скрипт для реальних умов - стара версія коду може потребувати іншої підготовки:

#!/bin/sh
# bisect.sh
composer install --no-interaction --quiet || exit 125   # не збирається - пропустити
php artisan migrate:fresh --env=testing --force --quiet || exit 125

php artisan test --compact --filter=VacancyExportTest

• exit 125 - коміт, на якому проєкт не збирається з не пов'язаних причин, не вважається «поганим» і не збиває пошук;
• база - тестова (--env=testing), щоб не зачепити робочу.

Тест, якого ще не було в історії: часто баг виявили сьогодні, а тест написали теж сьогодні - у старих комітах його немає. Рішення - тримати тест поза робочим деревом і копіювати його на кожному кроці:

cp /tmp/RegressionTest.php tests/Feature/RegressionTest.php
php artisan test --compact tests/Feature/RegressionTest.php
status=$?
rm tests/Feature/RegressionTest.php
exit $status

Корисні деталі:

• git bisect start --first-parent - іти лише по комітах злиття основної гілки: знайти, який PR зламав, без заходу в проміжні коміти гілок;
• git bisect log і git bisect replay - зберегти й повторити сесію;
• терміни good/bad можна замінити (--term-old=fast --term-new=slow) - bisect підходить і для пошуку регресії продуктивності, не лише помилки.

Докладніше в документації: git bisect run