Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[plugin proposal] Test/code quality reports #285

Open
cjbrooks12 opened this issue Jun 14, 2019 · 0 comments
Open

[plugin proposal] Test/code quality reports #285

cjbrooks12 opened this issue Jun 14, 2019 · 0 comments
Labels
feedback wanted Feedback from the community is greatly appreciated, to make this exactly what the community wants plugin proposal A proposal for a new plugin, which could be fully implemented by the current API under consideration Issue Status: Under consideration

Comments

@cjbrooks12
Copy link
Contributor

cjbrooks12 commented Jun 14, 2019

Description

Services like Codacy, Coveralls, CodeCov, etc. are all really nice, but for simple projects, it's kinda annoying to have to set them up for basic reporting. They're really best suited for large, fast-moving projects, but for small OSS projects I find it can be just a bit overkill. It would be nice if Orchid could read the reports for code coverage, test results, quality checks, etc. and create pages to display those reports, instead of passing those reports to other services.

In addition, it would be really awesome to connect these reports to the code documentation plugins. Imaging a single report with all code coverage metrics, but having a single class's coverage displayed on that class's documentation page.

I would welcome any thoughts, suggestions, or desired features that anyone has for this feature.

Requirements

A new plugin, maybe OrchidCodeReports, which has everything in it to scan the project and find the build-tool-generated reports. It probably doesn't make sense to have Orchid actually run those reports itself, as it would start to require full classpath management, etc.

Features

  • ReportsGenerator: a Generator to create pages for each report. A "report" is akin to a wiki section, blog post category, etc. in that it may consist of many pages, and each one is configured individually. Should 100% definitely also generate standalone SVG badges, which can be added to the project README, and can have their colors and text customized.
  • ReportAdapter interface: similar to the WikiAdapter, be able to customize the type of report generated for each report. Example adapters: codeCoverage (jacoco), testResults (gradle XML reports), codeStyle (checkstyle XML), apiDiff (japicmp) etc. They might need to be made more specific to the actual tools used (gradleCodeCoverage, jacocoCodeCoverage, etc.), or it might have different interface adapters for finding/parsing/interpreting build reports.
  • ReportComponent: Used to add report metrics to code documentation pages. Should ideally be added through the Archetype, and is able to automatically make the connection between the doc ID (e.g. the current class page) and the relevant report metrics. Can be configured to only show a specific report.
  • ReportMenu: Generates a menu that links to all individual reports. Can be configured to only show a specific report.
  • This will be included in the OrchidDocs bundle.

Dependencies

This plugin will loosely depend on the refactoring updates to code doc generation, #232, currently underway. The updates there will create a consistent interface across all code-doc plugins, and that known structure will be exploited by this plugin to create the links between reports and class pages. It is, however, like all plugin projects, completely independent of that connection, and can even work perfectly well if you choose not to include any code documentation in your Orchid build. The classes referenced in the reports simply will not have anything to link to, and text will be displayed statically, without a link.

@cjbrooks12 cjbrooks12 added under consideration Issue Status: Under consideration plugin proposal A proposal for a new plugin, which could be fully implemented by the current API labels Jun 14, 2019
@cjbrooks12 cjbrooks12 added the feedback wanted Feedback from the community is greatly appreciated, to make this exactly what the community wants label Jun 14, 2019
@cjbrooks12 cjbrooks12 pinned this issue Jul 18, 2019
@cjbrooks12 cjbrooks12 unpinned this issue Sep 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feedback wanted Feedback from the community is greatly appreciated, to make this exactly what the community wants plugin proposal A proposal for a new plugin, which could be fully implemented by the current API under consideration Issue Status: Under consideration
Projects
None yet
Development

No branches or pull requests

1 participant