git bisect run bisect automatico
Se si dispone di uno ./testscript automatizzato con stato di uscita 0 se il test è OK, è possibile trovare automaticamente il bug con 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
Ciò presuppone ovviamente che se lo script di test ./testviene rintracciato git, che non scompare in alcuni commit precedenti durante la bisection.
Ho scoperto che molto spesso puoi scappare semplicemente copiando lo script in-tree fuori dall'albero, e possibilmente giocando con PATHvariabili simili a, ed eseguendolo invece da lì.
Ovviamente, se l'infrastruttura di test da cui testdipende si interrompe su commit precedenti, allora non c'è soluzione e dovrai fare le cose manualmente, decidendo come testare i commit uno per uno.
Ho scoperto tuttavia che l'utilizzo di questa automazione spesso funziona e può essere un enorme risparmio di tempo per i test più lenti che si trovano nel tuo backlog di attività, in cui puoi semplicemente lasciarlo funzionare durante la notte e possibilmente avere il tuo bug identificato entro la mattina successiva, vale la pena il tentativo.
Più suggerimenti
Rimani sul primo commit non riuscito dopo bisect invece di tornare a master:
git bisect reset HEAD
start+ iniziale bade goodin una volta sola:
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
equivale a:
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
Guarda cosa è stato testato finora (da manuale goode bado run):
git bisect log
Uscita campione:
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
Mostra riferimenti positivi e negativi sul registro git per ottenere una migliore nozione del tempo:
git log --decorate --pretty=fuller --simplify-by-decoration master
Questo mostra solo i commit con un riferimento corrispondente, che riduce il rumore in modo radicale, ma include riferimenti generati automaticamente:
refs/bisect/good*
refs/bisect/bad*
che ci dicono quali impegni abbiamo contrassegnato come buoni o cattivi.
Considera questo repository di prova se vuoi giocare con il comando.
Il fallimento è veloce, il successo è lento
Qualche volta:
- il fallimento avviene rapidamente, ad esempio uno dei primi test si interrompe
- il successo richiede un po 'di tempo, ad esempio il superamento dei test falliti e tutti gli altri test a cui non ci interessa seguiranno
In questi casi, ad esempio supponendo che l'errore si verifichi sempre entro 5 secondi, e se siamo pigri a rendere il test più specifico come dovremmo, possiamo usare timeoutcome in:
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
Funziona da quando timeoutesce 124mentre il fallimento delle test-commanduscite 1.
Stati di uscita magici
git bisect run è un po 'esigente riguardo agli stati di uscita:
qualcosa sopra 127 fa fallire la bisection con qualcosa del tipo:
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
In particolare, una C assert(0)porta a a SIGABRTed esce con lo stato 134, molto fastidioso.
125 è magico e fa saltare la corsa git bisect skip.
L'intenzione è quella di aiutare a saltare le build rotte a causa di motivi non correlati.
Vedi man git-bisectper i dettagli.
Quindi potresti voler usare qualcosa come:
#!/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"
Testato su git 2.16.1.