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відслідковується, він не зникає на деяких попередніх фіксаціях під час поділу.
Я виявив, що дуже часто ви можете піти, просто скопіювавши сценарій дерева з дерева та, можливо, погравши зі 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, щоб краще зрозуміти час:
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)призводить до 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.