HBASE-29873 Improve the job summary for unit check

[Apache9]

… the job summary for unit check

[Apache9]

We need to add maven plugin if we want to specify build tool as maven, and we have this in maven plugin

function maven_initialize
{
  # we need to do this before docker does it as root

  maven_add_install compile
  maven_add_install mvnsite 
  maven_add_install unit

So there is no way for us to avoid running mvninstall for unit check...

Let's focus on improving the test output summary.

[Apache9]

Ah, we use parallel build so the log output are messed up...

Let me think how to better deal with, that we can find out which module the tests belong to...

[Apache9]

Here I also change the python script to take the yetus output directory as input, so later we could show more failing information on the job summary page, like error prone, spotless, checkstyle, etc.

[ndimiduk]

Here I also change the python script to take the yetus output directory as input, so later we could show more failing information on the job summary page, like error prone, spotless, checkstyle, etc.

We currently do show error prone, spotless, checkstyle on the job summary for the compile check. You want to add these also to the unit summary?

[ndimiduk]

Looks more robust. Can you add more test failures so that we can see how they're aggregated? In 7735 I put two method failures from one class and another failure method in another class so that I could see how it built the table. I guess here you should to that across large waves so that we can see how parallelism weaves them together? Or just ship it and see how it looks for a while?

[ndimiduk]

I think we want to keep this plugin filtered here -- we don't want a failure here to report -1, only -0, right? It'll get it's -1 vote on the compile check.

We added the separate compile step so that these checks would not be reported on multiple times.

[Apache9]

I think a mvninstall error will definately cause the whole job to fail? I agree that this check is redundant, but setting it to -0 does not help too much I suppose.

[Apache9]

Here I also change the python script to take the yetus output directory as input, so later we could show more failing information on the job summary page, like error prone, spotless, checkstyle, etc.

We currently do show error prone, spotless, checkstyle on the job summary for the compile check. You want to add these also to the unit summary?

Now we only report failure, without any detailed information, I mean we can add a special section for the detailed information, like which line is the root cause of the failure.

[Apache9]

Looks more robust. Can you add more test failures so that we can see how they're aggregated? In 7735 I put two method failures from one class and another failure method in another class so that I could see how it built the table. I guess here you should to that across large waves so that we can see how parallelism weaves them together? Or just ship it and see how it looks for a while?

I think the most robust way is to parse all the information from the xml file under the archiver directory. We use parallel building so the output of surefire plugin is messed up, I guess in some extreme corner cases, the Results section could also be messup and lead to incorrect parse result...

Let me try more failures here.