Conversation
90535b3 to
651f925
Compare
This patch adds the logic of report output merging into one singluar `.plist` file. Now analyze and check can be invoked with the `--plist-file-name` option, which if provided will merge all new `.plist` result files into the specified file name under the specified output report folder.
81813a5 to
9e66f53
Compare
| def merge_plists(results, output_path, plist_file_name): | ||
| """ | ||
| Merge the plist files generated by the analyzers into a single plist file. | ||
| Deletes the original plist files after merging. | ||
| """ |
There was a problem hiding this comment.
Any reason why we are not reusing the method introduced in #4152? That also merged multiple plist files, while also uniquing bug report with the same hash (as generated by get_report_path_hash(), not by the analyzer).
There was a problem hiding this comment.
Generally speaking, I'm highly against the fixation on a specific output format. Sure, plist is the format we use, and will likely use way past you and I bite the dust, but its still distracting. I prefer consistently naming user-facing configs like "output-single-file" instead of "plist-single-file".
On another issue, as I stated in my previous response, there is no reason not to unique the reports in the unified plist file, for which we already implemented a solution. Having the same thing be implemented twice needs more justification.
Also, I'm missing a great dose of "why" in the summary. Why do we need this feature? I understand that this in part to better support bazel projects. Why is it needed/advantegeous to generate a single plist files for them? These kinds of details should be most highlighted in the summary.
edit: also, I don't think the PR name has a character limit! :)
This patch adds the logic of report output merging into one singular
.plistfile. Now analyze and check can be invoked with the--plist-file-nameoption, which if provided will merge all new.plistresult files into the specified file name under the specified output report folder.