Flatten testsets during report generation #104
Conversation
| if depth > 0 || has_description(ts) | ||
| childts.description = ts.description * "/" * childts.description | ||
| end |
There was a problem hiding this comment.
Currently we only skip appending unnamed top-level test sets from the nested testset description. I think it would be reasonable to skip any unnamed testset at any level but didn't want to work through all of the repercussions of such a change at this time.
There was a problem hiding this comment.
I agree i would want to think about that a little more
|
CI isn't running as this doesn't use Update: Workflow has been updated to allow for PRs not based on |
Refactored the code to no longer flatten at the top-level when finishing the top-level `ReportingTestSet` and instead perform the flattening when we generate the JUnit XML report. Doing this allows introspecting of the nested `ReportingTestSet` structure and opens up the possibility of using this testset in other report generation which does support nesting.
omus
force-pushed
the
cv/flatten-refactor
branch
from
4579913
to
bcec677
Compare
| branches: | ||
| - master |
There was a problem hiding this comment.
for my education can you explain this chagne?
There was a problem hiding this comment.
Was changed to address this: #104 (comment)
The branches filter for the pull_request event restricts this workflow such that it only runs when a PR targets master (in this case) as the base branch. This PR originally didn't target master but another PR so the CI wouldn't run automatically. I don't see a good reason to restrict the CI workflow in these cases so I removed this.
| if depth > 0 || has_description(ts) | ||
| childts.description = ts.description * "/" * childts.description | ||
| end |
There was a problem hiding this comment.
I agree i would want to think about that a little more
Previously we would perform the testset flattening once we
finished the top-levelReportingTestSet. This PR changes the flattening to occur whenreportis called which is where it is necessary for JUnit XML report generation. Doing this allows introspecting of the nestedReportingTestSetstructure and opens up the possibility of using this testset in other report generation which does support nesting.Additionally, the code changes here eliminates the need for
handle_top_level_results!.