-
-
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
[QueryStringStatic] service #3024
[QueryStringStatic] service #3024
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.
Thanks! I left some preliminary comments.
} | ||
} | ||
|
||
handle(namedParams, queryParams) { |
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.
It would be good to validate the queryParams
using Joi, as we've done in e.g. the dynamic badge. It will ensure that message
is a string or numeric string, and not e.g. an array. (same issue as #2854)
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 added validation as best as I could figure out how. I'm sure there's a better way.
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.
.get( | ||
'/static/v1.svg?label=label&message=message&color=notacolor&style=_shields_test' | ||
) | ||
.expectJSON({ name: 'label', value: 'message', color: null }) |
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.
These seem like they are testing functionality in coalesceBadge
+ BaseService. There's already a "set color" test at the bottom, so how about removing all of these?
If it seems important to add more tests of that code I would prefer we find a way to do it with a unit test instead of a service test, as the unit tests get run more frequently.
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.
Fair point.
.get( | ||
'/static/v1.svg?label=best-license&message=Apache-2.0&color=blue&style=_shields_test' | ||
) | ||
.expectJSON({ name: 'best-license', value: 'Apache-2.0', color: 'blue' }) |
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.
The "Shields-encoded dash" is the unusual escaping used in the url-based static badge. It doesn't seem relevant here and could be removed.
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.
Good point!
I updated the PR title so the service tests will run starting with the next build. |
45a9b72
to
f0c5679
Compare
So I guess the next step here is to update the shields.io page and add documentation for this. Should it be more like the endpoint badge, on a separate page, or should it be a widget similar to the current static badge, or something else? Maybe the most simple thing would be to add another output url on the current static widget. |
Yea, seems fine to do the simple thing for now. That text is in flight in #3032 so perhaps best to get that merged first. |
} | ||
} | ||
|
||
handle(namedParams, queryParams) { |
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.
e5f36ff
to
e8e19ea
Compare
e8e19ea
to
2ca144c
Compare
3aca1ef adds a snippet on the front page, which looks like this I'm not sure how you want to treat the new static urls vs the old ones. With the commit f9b5c20 I've updated the fronted to use the /static/v1.svg urls everywhere, which may be a bit much, idk. In order to keep the history linear I usually like to do |
We keep PRs to single units of work and use a squash merge workflow, and as a result can optimize the history in PRs for people who are following the PRs. So please merge master into your branch, and we'll squash it down when it's done. |
Thanks for carrying this forward!
Looks good! I'd like to ship a second version of the URL path version that is a bit friendlier. But this feature is intended for (1) easy programmatic generation and (2) complicated text that is otherwise hard to escape. So, could you put the new text below instead of above? Also I don't think there's a need to label it beta. We've been thinking about this for a long time and I'm feeling confident in the changes you're making. 😁
Again some of the code you're changing is in flight in #3032; so apologies, but I think we need to land that first. I'd lean toward using the old badge everywhere else because the URLs are more readable than query strings. If we get a more streamlined URL-path version down the line we could switch them over. |
Sounds reasonable. I'll revert f9b5c20. |
This PR is now pending on the merge of #3032 since I merged |
Thanks for the updates! Will approve and merge when #3032 is in. |
Ref #2673
This is WIP (no updated documentation yet) and is based on PR #3012