Shouldn’t you be, in general, separating out new functionality from old fixes?
Shouldn’t those “fixing bugs we gained in the past” be their own MR that can be read, reasoned about and have evaluated test coverage?
Shouldn’t those “fixing bugs we gained in the past” be their own MR that can be read, reasoned about and have evaluated test coverage?
In the case of what I'm currently working on, filing bugs for every issue I found, and then factoring out each fix, and then running each change through the 8 hour ci/cd system, and hoping an unrelated issue doesn't get misattributed to me... No, I'd rather just wrap it up into one coherent refactoring change and be done with it because when I'm done there are several more like it waiting for my attention.
1. Track code coverage from all current test cases in your big 8hr runs.
2. Index the coverage so it goes testcase name -> methods touched.
3. On every commit run an agent which looks at the diffs, tries to predict which tests the code being edited is touching, and run just those tests (or a random subset if there are too many).
Once you have this you can also automatically kick off builds every 8hr that contain all the previously submitted patches. Once that is done, if a test begins to fail, it can automatically bisect the history to find change, and notify the author.
You could also get these benefits with a Bazel like build system which can cache test executions so others don't need to rerun them if the binary is not changed.