-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Add new service for CII Best Practices badges [CIIBestPractices] #2477
Conversation
|
I'll review this shortly. In the meantime, here's the link to a Heroku review app with the contents of this PR deployed. |
Awesome, thanks @PyvesB! |
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.
Unfortunately, the Heroku review app broke in the meantime, we've got something misconfigured somewhere.
Overall this looks like good quality work to me, thank you for your contribution @calebcartwright! I've left some comments on things I believe can be improved. 😉
.get(`/level/abc.json`) | ||
.expectJSON({ name: 'cii', value: 'project not found' }) | ||
|
||
t.create('level: unknown project') |
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.
I think the live: unknown project
test is enough as far as unknown projects are concerned. The bit of code we're testing is the 404: 'project not found'
, having three additional mocked tests will not improve our coverage nor give us more confidence that the badge is wired up correctly.
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.
Just to clarify, is the suggestion/ask for me to remove those other tests? It doesn't really matter to me either way so just let me know. I agree that the tests won't increase code coverage with the current implementation, but as far as my initial thinking goes - I like to have some tests that validate expected behavior, regardless of what the current implementation code flows allow (more blackbox-ish).
There's 3 different badges and the expected behavior would be project not found
for each badge. Absolutely true that with the current implementation that will always be the result regardless of which of the 3 badges are selected (and thus those tests are covering the same lines) but in theory a different implementation of the service could be used in the future where that may not necessarily be true.
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.
Yes, my suggestion was initially to remove all the project not found tests apart from the live one. You're right by saying that we might need additional ones in the future if the implementation changes, however in the meantime they (slightly) slow down our test suite and add code to maintain. ^^
keywords, | ||
}, | ||
{ | ||
title: 'CII Best Practices Default', |
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.
Maybe we could make the meaning of "default" clearer by adding some documentation to the example? Pretty much taken from your PR's description: "This badge uses the same message and color scale as the native CII one, but with all the configuration and goodness that Shields provides!". You can refer to our Matrix badge for an example of how to add documentation.
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.
level
- uses the CII level for the badge message with a simple color schemepercentage
uses the CII score/percentage with the standard Shields percentage color schemedefault
- uses the same badge message & color scale as the native CII badge provides, but with all the configuration and goodness that Shields provides! (I'm not crazy aboutdefault
as the path name/label but I wasn't sure what else to call this one)
status
or summary
might be a more descriptive name that emphasizes the content that’s being shown.
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.
Yeah I was having similar thoughts myself, but just wasn't sure what to put in there for the documentation. I like the idea though!
@paulmelnikow - are you suggesting status
or summary
as a replacement for default
(both of which are far better than default
) and/or in place of the other two (level
or percentage
)
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.
i changed default
to summary
Thanks again for the feedback! Think I addressed everything with the exception of one question to clarify whether some of the tests should be removed. Also the circleci:danger job is failing on |
Thanks for addressing my review comments! I've clarified the one regarding the project not found tests. I've also kicked the CI server again, that spurious error seems to have gone away. 😉 |
Alrighty then, tests removed as requested |
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.
CI checks all green, performed some last sanity checks with a review app. Thanks for your work, let's get this merged! 👍
Excellent, much appreciated. Now I need to see which issues I can work on next! |
@calebcartwright I noticed that you had started a discussion in #2347, maybe it's a good one to tackle? If you're more interested in reviewing something at this point, #2470 is probably a good choice as well. 😉 |
Thanks @PyvesB and yeah the Nexus service one is pretty high on my list (especially since I haven't refactored a legacy service yet), but happy to take a look at the PR as well if it's ready for review. @paulmelnikow mentioned in another thread that there was plenty of work to do here, so I'm just happy to contribute any way I can. If there's anything in particular I can to do to help please let me know, otherwise I'm just perusing the open issues for ones I think I can work on. |
Adds support for badges from CII Best Practices which closes #1530
List of projects can be found at https://bestpractices.coreinfrastructure.org/en/projects for reference
I've never used the service before so some comments/info based on what I've seen:
tiered_percentage
in the API response)in_progress
for score of 0-99 (inclusive)passing
for score of 100-199 (inclusive)silver
for score of 200-299 (inclusive)gold
for a perfect score of 300100
the badge message includes the score percentage with a wide array of colors, otherwise the badge message is simply the level)As such, I decided to add support for 3 different types of badges for CII Best Practices Data that will give end users a lot more flexibility over the native CII badge:
level
- uses the CII level for the badge message with a simple color schemepercentage
uses the CII score/percentage with the standard Shields percentage color schemedefault
- uses the same badge message & color scale as the native CII badge provides, but with all the configuration and goodness that Shields provides! (I'm not crazy aboutdefault
as the path name/label but I wasn't sure what else to call this one)