I know many of you are probably lucky enough to use GitHub Actions. Some of us, me included, have to deal with Bitbucket Pipelines.
Perhaps your experience is different, but I have found myself more than once watching a pipeline degrade so unpredictably that its usual timing becomes meaningless: the log still moves, but I can no longer tell where the build is in the run or whether it will finish in five minutes or fifty.
Add your boss pushing to get a release out of the door and asking, "Is it going to be ready soon?" Now you are completely cooked — refreshing the log, sweating, and unable to say whether the pipeline is merely slow, completely stuck, or five minutes from finishing.
It feels as if some machine in the Bitbucket fleet is running pipelines from several projects at once, virtually sharing its CPUs among their runners and struggling like hell. Can I prove that this is exactly what happens behind the curtain? No.
Now combine that with a Surefire configuration using forkCount=1C and the requested size: 16x pipeline step, so naturally we try to use the capacity — we pay for the build minutes, after all.
When the underlying performance becomes unpredictable, there is a point where test output stops being information and starts becoming anxiety. The CI job says the tests are running. Surefire prints the suites that finish. Nothing has failed. But ten minutes later, the question you actually care about is still unanswered:
How much is left?
Did 12 suites finish out of 20, or out of 600? Is the build moving normally, crawling through one unusually slow test, or stuck altogether? Should you wait, investigate, or restart it?
Surefire's output is a good record of what has happened. It is not a progress indicator. It tells you which suite just completed, but gives you no run-wide denominator and no sense of position.
That uncertainty has a cost. Not in CPU time, but in attention. You keep returning to the process output. A reviewer keeps refreshing the CI job. Someone kills a build that looked frozen even though it was nearly finished. Long test runs turn developers into human progress bars, reconstructing the state of the build from class names and memory.
Maven Surefire Progress Reporter adds the missing number:
[PROGRESS] Discovered 217 eligible test suites
[PROGRESS] Suites 117/217 (53.9%) | elapsed 11:42
That line is not sophisticated, and that is precisely the point.
If the number keeps moving, the build is alive. If it stays at 117/217 for ten minutes, you know where the slow stretch began. If it says 211/217, you probably should not restart the job or close the laptop just yet.
The reporter preserves Surefire's normal console and file reports and appends suite-level progress after each completion. It estimates the total from compiled test classes before execution begins and shares the counter across Surefire forks. It does not change which tests run or how their results are recorded.
Add the reporter to Surefire and keep using Maven as before. The repository README has the complete configuration.
Progress reporting does not make a test suite faster. It makes the waiting legible.
Your feedback and comments are highly appreciated.
Top comments (0)