refactor: adjust rule details format in generated markdown report#740
Draft
refactor: adjust rule details format in generated markdown report#740
Conversation
0a05984 to
ec65191
Compare
Rather than generating one big table, with lots of wide columns, this generates one section, including a single table, per rule, to remove redundant information and efficiently display all the data associated with the violations of a given rule. Signed-off-by: Dustin Popp <[email protected]>
ec65191 to
beb0692
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is something I'm proposing for 2.x. Happy to take feedback on the design!
Rather than generating one big table, with lots of wide columns, this generates one table per violation to be more extendable with new fields. It also ends up being more consistent with how the data is displayed in the CLI output.
Here is an example of how it would look after this change:
Detailed results
🔴 operation-operationId-unique
Every operation must have unique "operationId".
🔴 ibm-no-array-responses
Operations should not return an array as the top-level structure of a response
🔴 no-$ref-siblings
$ref must not be placed next to any other properties
🟠 ibm-openapi-tags-used
A tag is defined but never used
🟠 ibm-response-status-codes
Operation responses should include at least one success status code (2xx)
🟠 ibm-request-and-response-content
Request bodies and non-204 responses should define a content object
🟠 ibm-operationid-naming-convention
operationIds should follow naming convention
🟠 ibm-schema-description
Schemas should have a non-empty description
🟠 ibm-success-response-example
Response bodies should include an example response
🟠 ibm-securityschemes
A security scheme is defined but never used
🟠 ibm-property-description
Schema properties should have a non-empty description
🟠 ibm-string-attributes
String schemas should define property 'pattern'
🟠 oas3-unused-component
Potentially unused component has been detected.