git bisect run bissecção automática
Se você tiver um ./testscript automatizado com o status de saída 0, se o teste for bom, poderá encontrar automaticamente o erro com 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
Isso supõe, é claro, que, se o script de teste ./testfor rastreado pelo git, ele não desaparecerá em algum commit anterior durante a bissecção.
Descobri que muitas vezes você pode se safar apenas copiando o script in-tree da árvore e, possivelmente, jogando com PATHvariáveis -like, e executando-o a partir daí.
Obviamente, se a infraestrutura de teste da qual testdepende as confirmações mais antigas, não há solução e você terá que fazer as coisas manualmente, decidindo como testar as confirmações uma a uma.
Descobri, no entanto, que o uso dessa automação geralmente funciona e pode economizar muito tempo em testes mais lentos em sua lista de tarefas, em que você pode deixá-lo executar da noite para o dia e possivelmente ter seu bug identificado na manhã seguinte, vale a pena. a tentativa.
Mais dicas
Permaneça no primeiro commit com falha após a divisão em vez de voltar para master:
git bisect reset HEAD
start+ inicial bade goodde uma só vez:
git bisect start KNOWN_BAD_COMMIT KNOWN_GOOD_COMMIT~
é o mesmo que:
git checkout KNOWN_BAD_COMMIT
git bisect start
git bisect bad
git bisect good KNOWN_GOOD_COMMIT
Veja o que foi testado até agora (por manual goode badou run):
git bisect log
Saída de amostra:
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
Mostre boas e más referências no git log para obter uma noção melhor do tempo:
git log --decorate --pretty=fuller --simplify-by-decoration master
Isso mostra apenas confirmações com uma referência correspondente, o que reduz muito o ruído, mas inclui referências do tipo geradas automaticamente:
refs/bisect/good*
refs/bisect/bad*
que nos dizem quais confirmações marcamos como boas ou ruins.
Considere este repositório de teste se quiser brincar com o comando.
O fracasso é rápido, o sucesso é lento
As vezes:
- a falha ocorre rapidamente, por exemplo, um dos primeiros testes
- o sucesso leva um tempo, por exemplo, o teste quebrado passa e todos os outros testes com os quais não nos importamos seguem
Nesses casos, por exemplo, supondo que a falha sempre ocorra em 5 segundos, e se tivermos preguiça de tornar o teste mais específico como realmente deveríamos, podemos usar timeoutcomo em:
#!/usr/bin/env bash
timeout 5 test-command
if [ $? -eq 1 ]; then
exit 1
fi
Isso funciona desde que timeoutsai 124enquanto a falha de test-commandsaídas 1.
Status de saída mágica
git bisect run é um pouco exigente quanto aos status de saída:
qualquer coisa acima de 127 faz com que a bissecção falhe com algo como:
git bisect run failed:
exit code 134 from '../test -aa' is < 0 or >= 128
Em particular, um C assert(0)leva a SIGABRTe sai com o status 134, muito irritante.
125 é mágico e faz com que a corrida seja pulada git bisect skip.
A intenção disso é ajudar a pular compilações quebradas devido a razões não relacionadas.
Veja man git-bisectpara os detalhes.
Então você pode querer usar algo como:
#!/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"
Testado no git 2.16.1.