git bisect run автоматический раздел
Если у вас есть автоматический ./testскрипт, который имеет статус выхода 0, если тест в порядке, вы можете автоматически найти ошибку с помощью bisect run:
git checkout KNOWN_BAD_COMMIT
git bisect start
# Confirm that our test script is correct, and fails on the bad commit.
./test
# Should output != 0.
echo $?
# Tell Git that the current commit is bad.
git bisect bad
# Same for a known good commit in the past.
git checkout KNOWN_GOOD_COMMIT
./test
# Should output 0.
echo $?
# After this, git automatically checks out to the commit
# in the middle of KNOWN_BAD_COMMIT and KNOWN_GOOD_COMMIT.
git bisect good
# Bisect automatically all the way to the first bad or last good rev.
git bisect run ./test
# End the bisect operation and checkout to master again.
git bisect reset
Это, конечно, предполагает, что если тестовый скрипт ./testотслеживается в git, он не исчезает при более раннем коммите во время деления пополам.
Я обнаружил, что очень часто вы можете уйти, просто скопировав скрипт из дерева из дерева, и, возможно, поиграв с PATHпеременными, подобными переменным, и запустив его вместо этого.
Конечно, если тестовая инфраструктура, от которой testзависит, прерывается от старых коммитов, то решения не существует, и вам придется делать что-то вручную, решая, как тестировать коммиты один за другим.
Однако я обнаружил, что использование этой автоматизации часто работает и может значительно сэкономить время для более медленных тестов, лежащих в вашем списке невыполненных задач, где вы можете просто позволить ему работать в одночасье и, возможно, определить вашу ошибку к следующему утру. попытка
Дополнительные советы
Оставайтесь на первом неудачном коммите после деления пополам вместо того, чтобы возвращаться к master:
git bisect reset HEAD
start+ начальный badи goodза один раз:
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
такой же как:
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
Посмотрите, что было проверено до сих пор (вручную goodи badили run):
git bisect log
Пример вывода:
git bisect log
git bisect start
# bad: [00b9fcdbe7e7d2579f212b51342f4d605e53253d] 9
git bisect bad 00b9fcdbe7e7d2579f212b51342f4d605e53253d
# good: [db7ec3d602db2d994fe981c0da55b7b85ca62566] 0
git bisect good db7ec3d602db2d994fe981c0da55b7b85ca62566
# good: [2461cd8ce8d3d1367ddb036c8f715c7b896397a5] 4
git bisect good 2461cd8ce8d3d1367ddb036c8f715c7b896397a5
# good: [8fbab5a3b44fd469a2da3830dac5c4c1358a87a0] 6
git bisect good 8fbab5a3b44fd469a2da3830dac5c4c1358a87a0
# bad: [dd2c05e71c246f9bcbd2fbe81deabf826c54be23] 8
git bisect bad dd2c05e71c246f9bcbd2fbe81deabf826c54be23
# bad: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05] 7
git bisect bad c536b1b7242d5fcf92cd87e9a534bedb1c0c9c05
# first bad commit: [c536b1b7242d5fcf92cd87e9a534bedb1c0c9c0
Покажите хорошие и плохие ссылки на git log, чтобы получить лучшее представление о времени:
git log --decorate --pretty=fuller --simplify-by-decoration master
Это показывает только коммиты с соответствующей ссылкой, которая уменьшает шум, но включает автоматически сгенерированные ссылки типа:
refs/bisect/good*
refs/bisect/bad*
которые говорят нам, какие обязательства мы отметили как хорошие или плохие.
Рассмотрите это тестовое репо, если вы хотите поиграть с командой.
Отказ быстр, успех медленный
Иногда:
- сбой происходит быстро, например, один из первых тестов прерывается
- успех занимает некоторое время, например, пройденные тесты пройдены, и все остальные тесты, о которых мы не заботимся, следуют
Для таких случаев, например, предположим, что сбой всегда происходит в течение 5 секунд, и если нам лень сделать тест более конкретным, чем мы должны, мы можем использовать timeoutкак
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
Это работает с timeoutвыходами в 124то время как отказ test-commandвыходов 1.
Магические статусы выхода
git bisect run немного требователен к статусам выхода:
все, что выше 127, приводит к сбою деления пополам с чем-то вроде:
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
В частности, C assert(0)ведет к a SIGABRTи выходит со статусом 134, что очень раздражает.
125 - это магия, с которой можно пропустить бег git bisect skip.
Цель этого состоит в том, чтобы помочь пропускать неработающие сборки по несвязанным причинам.
Смотрите man git-bisectподробности.
Так что вы можете использовать что-то вроде:
#!/usr/bin/env bash
set -eu
./build
status=0
./actual-test-command || status=$?
if [ "$status" -eq 125 ] || [ "$status" -gt 127 ]; then
status=1
fi
exit "$status"
Проверено на git 2.16.1.