Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Automated Git bisect
Inspired by this comment thread, is there a way to automate git bisect with a new test (and a known good state)? The way things usually work for me is…
- Oh no! Reproducible bug is found.
- (Manually) find a release where it wasn't present.
-
git bisectand flag the identified starting/ending commits as good/bad behavior. - Git suggests commits to build and test, and asks me to flag them as good or not.
- Repeat this step Log(O) times.
- Git points to a commit where the bug was introduced.
What I want to do is this…
- Oh no! Reproducible bug is found.
- Write a unit test to identify the problem.
- Find a release where the bug wasn't present.
- Maybe manually. Maybe this can be automated, too?
-
git bisectand flag the identified starting/ending commits as good/bad behavior. - Git suggests commits to build and test.
- Some process builds the code and runs my new unit test to flag the suggested commits as good or bad.
- Git points to a commit where the bug was introduced.
Can I set up a system where I can provide these inputs and find out what commit is the culprit?
- The build script
- The test runner
- The new unit test (stored somehow: Stash? New commit? Just on disk somewhere?)
- The "bad" commit
- (If necessary) the "good" commit
1 answer
Of course you can. The script should probably be external to the repository (either stored outside it or in the working tree but not committed and not conflicting with anything in history), otherwise you'll have problems with different versions of the runner being used to test different versions.
The git bisect run command is what you are looking for. man git bisect and look for the "Bisect run" header for more info. The TL;DR is that you write a script that does any cleanup/setup/configure/build work you need, then runs a test, then exits with 0 for success, 1 for failure, or 125 to skip.
To further automate this you'll have to make some assumptions such as the oldest possible version your test can be expected to pass on, or include that logic in your runner to output skips. Heuristics for this part are very hard though and it really makes more sense for you to input a starting point (like the last major release tag).
0 comment threads
0 comment threads