Commit 4cb0190
committed
Runner: fix progress bar when running in parallel
Rodrigo and me came across this while debugging something completely different.
Turns out the split between fixable/fixed error vs warnings, which was necessary in 4.0 to allow for the exit code change, was breaking the progress bar display when parallel processing was enabled.
Basically, parallel processing "mocks" the accumulated fixable/fixed error and warning counts via a `DummyFile` before calling `Runner::printProgress()`.
Then the `Runner::printProgress()` method calls the `File::getFixed()` method, however, that method doesn't look at the "split" fixed counts, but at the accumulated total fixes, but as this is a mocked `DummyFile`, that number will always be `0`.
IIRC, updating the `File::getFixed()` method to calculate the number based on the split fixed errors and warnings was breaking other things, which is why it was left as-is.
The down-side of that, as we now discovered, is that the progress bar when running in parallel would always just show a `.` and not the `F` when files were fixed.
Either way, this should be fixed now.
Includes a test via the new bashunit end-to-end testsuite.1 parent bd2d185 commit 4cb0190
2 files changed
+8
-1
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
791 | 791 | | |
792 | 792 | | |
793 | 793 | | |
794 | | - | |
| 794 | + | |
795 | 795 | | |
796 | 796 | | |
797 | 797 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
26 | 26 | | |
27 | 27 | | |
28 | 28 | | |
| 29 | + | |
| 30 | + | |
| 31 | + | |
| 32 | + | |
| 33 | + | |
| 34 | + | |
| 35 | + | |
29 | 36 | | |
30 | 37 | | |
31 | 38 | | |
| |||
0 commit comments