plugins.xunit: Use job-dir-name as name #2922
Conversation
Currently we use "avocado" as a suite name, let's use job-dir which is quite useful when matching xml results to output directories. Signed-off-by: Lukáš Doktor <ldoktor@redhat.com>
| @@ -90,7 +90,7 @@ def _create_failure_or_error(self, document, test, element_type, | |||
| def _render(self, result, max_test_log_size): | |||
| document = Document() | |||
| testsuite = document.createElement('testsuite') | |||
| testsuite.setAttribute('name', 'avocado') | |||
| testsuite.setAttribute('name', os.path.basename(os.path.dirname(result.logfile))) | |||
There was a problem hiding this comment.
Where should I see this in Jenkins' display of the xunit result?
There was a problem hiding this comment.
Well it's in the xml results, Jenkins knows about it and it shows it at least when you open the individual result:
There was a problem hiding this comment.
(First image shows just results, second and third shows test-results where you can see the (from job-2018-11-30..) which without this PR is just (from avocado).)
There was a problem hiding this comment.
Ahh. Yes. I see. I have to click the test result link from the testReport/ url. I typically save the forward (clicking the test links) and back action by just clicking the those big plus (and minus) sign expander/collapsers. Apart from that new (from jobs YYYY-MM-DDTHH.MM-UUID) I didn't see anything that the cost of clicking links (and having to go back) was worth.
There was a problem hiding this comment.
Yeah, I know, my aim was more towards automation and having this useful info in the results itself. Anyway you can always propose adding this field to main Jenkins summary, especially if you combine results from multiple jobs.
There was a problem hiding this comment.
Anyway looking at junit reference: https://github.com/windyroad/JUnit-Schema/blob/master/JUnit.xsd there is no other way unless we want to inject it into stdout/stderr/name/classname/message/traceback. As Jenkins is our primary target for xunit and it only provides the testsuite-name buried deeply in results, we might consider extending these. Ideal would be the classname, but I'm not sure about the consequences (it'd better differentiate the test results for multiple jobs while it'd avoid grouping the results in case we want group multiple-job-results together).
What I mean:
avocado run suite.yaml --some-setting
avocado run suite.yaml --other-setting
would show individual results for each avocado execution while now it groups the same tests from both executions into a single classname.
Actually when I started I wanted to use classname as jobname, because it was more natural, but when I looked at other tools they like grouping results per classname. It's a tough call...
There was a problem hiding this comment.
... I mean in java testing I understand you might want to get aggregated results per failed class, but in generic testing framework like Avocado it usually doesn't make sense (and often I need to look at ExternalRunner, FailTest, ... results individually only to see regressions/improvements). When adding xunit results we simply followed the description in junit, which is classname but it could be changed.
There was a problem hiding this comment.
I mean this is what I had in mind. It doesn't follow the classname guides, but IMO it more reflects the avocado purpose:
There was a problem hiding this comment.
Yeah. That is nice. I can appreciate the limitations that junit puts on being able to do any of this in a nice way.
|
@ldoktor @brianjmurrell IIUC, this is a valid improvement, given the limitations of JUnit/Jenkins (use of JUnit). If you guys agree, I can go ahead and merge this. |
|
Yes, it definitely improves on the current situation. The need to click through to the results is a pity, but still provides information that I don't know is available any other way. |
Currently we use "avocado" as a suite name, let's use job-dir which is
quite useful when matching xml results to output directories.
Note I considered using uid, which is available directly in
results, but the job-dir seems better.@brianjmurrell any suggestions?