-
Notifications
You must be signed in to change notification settings - Fork 7
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
feat(DPE-35): Created Collections rules #86
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! The impact overall is pretty minimal, so I'd say lets go ahead and roll this out incrementally starting Monday Morning 🫡
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some considerations. Also, I'm a bit worried about making too many assumptions about endpoints being collections. What is the impact seen on specifically network API related specs for these? like Documents / Items / Printables? (sps-missing-pagination-query-parameters and sps-no-collection-paging-capability)
Here are the results of the Summary of performance testing:
Here are the results of the Summary of Impact testing:
This resulted in 16 new errors.
|
…paging-capability to warnings instead of errors
…ify the new behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Just a few spelling issues
rulesets/test/collections/sps-hybird-filtering-exists-with-root-filter.test.js
Outdated
Show resolved
Hide resolved
rulesets/test/collections/sps-hybird-filtering-exists-with-root-filter.test.js
Outdated
Show resolved
Hide resolved
rulesets/test/collections/sps-hybird-filtering-exists-with-root-filter.test.js
Outdated
Show resolved
Hide resolved
…t-filter.test.js Co-authored-by: Mark DeBeer <me@markdebeer.com> Signed-off-by: Ethan Honzik <105084033+EthanHonzikSPS@users.noreply.github.com>
…t-filter.test.js Co-authored-by: Mark DeBeer <me@markdebeer.com> Signed-off-by: Ethan Honzik <105084033+EthanHonzikSPS@users.noreply.github.com>
…t-filter.test.js Co-authored-by: Mark DeBeer <me@markdebeer.com> Signed-off-by: Ethan Honzik <105084033+EthanHonzikSPS@users.noreply.github.com>
# [1.13.0](v1.12.0...v1.13.0) (2024-08-12) ### Features * **DPE-35:** Created Collections rules ([#86](#86)) ([1ad59f3](1ad59f3))
Impact testing results are about 8 more errors in total. The execution time for the impact testing is within a second or so compared to the current ruleset in the main branch.
Performance testing results are okay. These changes will create about 700 more errors or warnings within this Open API document suite we use. About 564 of those 700 errors/warnings are mainly concentrated in a few documents. The two rules
sps-missing-pagination-query-parameters
andsps-no-collection-paging-capability
are the ones that are causing the most errors since not all GET endpoints are not designed with collections capabilities. Execution time is still within a second or so of the current ruleset on the main branch.