-
-
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
Refactor badge color functions #2742
Conversation
- Replace the idea of color schemes with the idea of named colors (since none of our colorschemes have used `colorA`) - Pass through the normalized color to `_shields_test` to harmonize with BaseService and simplify testing - Update service tests - Move responsibility for color generation into the npm package - Remove several color helper functions and their tests - Update gh-badge public API to accept `color` and `labelColor`
|
95876a0
to
24c1178
Compare
This pull request introduces 1 alert when merging 628618f into fc4ed93 - view on LGTM.com new alerts:
Comment posted by LGTM.com |
Confident at this point that the failing service tests are unrelated to these changes. |
I've had a go at reviewing this. I'll leave a few comments but it probably needs another pass. One of the issue I'm hitting trying to test is that editing stuff in the modal popups in the front end is throwing:
which is making it difficult to test overrides, logos etc |
services/base.js
Outdated
color = coalesce(serviceColor, defaultColor, 'lightgrey') | ||
} else { | ||
color = coalesce(overrideColor, serviceColor, defaultColor, 'lightgrey') | ||
} |
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.
This section will want updating to account for #2740
# Conflicts: # services/dub/dub.tester.js
Ah, thanks. Given TypeScript, the preferred null value these days is |
Wait, sorry, I can't seem to reproduce the problem you're seeing. What are the steps to reproduce? I did just merge master into this branch so it's possible but unlikely that took care of it. |
Should we also run these changes against all service tests to validate there's no unexpected color change behavior? |
Yea, I did the full service test run in a number of the earlier builds, and cleaned up all the failures that seemed to be related. It's possible one or two have crept in since then, though at this point I think we can catch them more easily just after merging. |
@chris48s This issue is fixed, by the way. |
Ah sorry, I missed that |
Tangential question, but have we ever evaluated the feasibility of having Coveralls chime in on PRs with info about coverage changes? I imagine that could get tricky given the different test runs we have (and I know those coverage bots can get a little spammy on some PRs), but I think that could be valuable in some cases, especially for the core code. As was mentioned in a different thread the other day, there's ~40k lines of code in this project, most of which I'm still personally unfamiliar with. I know for me it would be really helpful during some PR reviews to be able to see that all the tests for that code are passing and coverage is 100% (or at least hasn't dropped), especially when dealing with sections of the code base I'm unfamiliar with |
There was a little discussion in #1584 and I wrote a bit the other day in #2756 (comment). I think ideally we have two suites:
1 seems easier to build. We could start there. Ideally if we can find a way to hack this with Coveralls, I think we should do that… it'd involve somehow keeping the two coverage runs separate. It might be possible if we switch |
I agree with targetting/emphasizing the 1. Core option I suppose we could leverage multiple .nycrc files, and perhaps another option would be to use Coveralls for one run and maybe a different service like Codecov for another? I'd venture to say others have encountered a similar scenario before (for example monorepos) and wanted coverage on different parts so I'd be curious to see what others have done. |
Also as I read through #1584 I realize I am just repeating things you've all already thought of 😆 |
While searching for Coveralls docs I found this from codecov: https://docs.codecov.io/docs/flags. I'll see what I can find on Coveralls and will open another issue if need be to avoid taking this PR any more off topic! |
Ooh, possibly useful: https://stackoverflow.com/a/49907438/893113 |
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.
Sorry - hadn't clocked this was fixed. Done a bit more testing. Should be good to go
Fabulous! Thanks for reviewing. I know this was kind of a bear. 🐻 Merge conflict sorted. |
Numeric colors weren't properly being handled by `makeBadge` after #2742. Since this function really does not need to be accepting colors as strings, rather than make the function more lenient to work with Scoutcamp, I coerced the types of the colors on the way in. Two tests cover the functionality in the modern service. I don't feel strongly that the legacy version needs coverage at this point, though I've added one for the moment on the github languages badge where this manifested. Fix #2778
colorA
)_shields_test
to harmonize with BaseService and simplify testingcolor
andlabelColor
This is a precursor to refactoring some of the logo code for #2473.