Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

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

+5
−0

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 bisect and 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 bisect and 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
History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+3
−0

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).

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »