[xwiki-devs] Analysis of TPC loss on xwiki-commons-job since 2019-01-01

Hi Thomas and all, I’ve just done the analysis of the xwiki-commons-job TPC loss displayed on http://maven.xwiki.org/site/clover/20190108/XWikiReport-20190101-2330-20190… (and it’s still the case today on http://maven.xwiki.org/site/clover/20190202/XWikiReport-20190101-2330-20190…). xwiki-commons-job 84.3812 84.2416 -0.1395 -0.0002 There were only 2 classes that have had changes in TPC: * DefaultJobProgress - lowered TPC * AbstractRequest - increased TPC But there’s more lowering than increasing globally which is why it’s in red. Specifically the lowering happened in 2 places: * http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo… * http://maven.xwiki.org/site/clover/20190108/clover-commons+rendering+platfo… vs http://maven.xwiki.org/site/clover/20190101/clover-commons+rendering+platfo… Note that no source code changed in the job module. Conclusions: * It was hard to track and I need to improve the report to show a package level difference too and not just modules, at least for modules going down. Actually, even better would be a class level difference too for modules going down. * In this case, I believe we had some bugs in XWiki somewhere that led to hitting the "Could not find any matching step for source [{}]. Ignoring EndStepProgress.” error. Could someone confirm that, it rings a bell to me? * It also shows there’s no module level tests (ie unit tests) that go on in this IF and it would be good to add one to prove that we get a log when we have an end without a start. It’s interesting because this is a use case where our global TPC went down because we fixed a bug (and thus indirectly we enter into less code). It mostly highlights that we don’t tests this case and we should. Thanks -Vincent