Add alternative static badge

[RedSparr0w]

Closes #815
Add an alternative static badge similar to the badge/dynamic/json link,
Uses the uri /badge/static.svg

Examples:

Uri	Badge
/badge/static.svg?label=Static&value=Badge
/badge/static.svg?label=Static&value=Badge&colorscheme=brightgreen
/badge/static.svg?label=Static&value=Badge&colorB=FF00FF

Still need to add tests

[shields-ci]

	Warnings
⚠️	This PR modified the server but none of the service tests. That's okay so long as it's refactoring existing code.

	Messages
📖	✨ Thanks for your contribution to Shields, @RedSparr0w!

Generated by 🚫 dangerJS

[paulmelnikow]

Presumably the justification here is that this is a much easier way to programmatically generate static badge URIs, and also avoids the need for a user to learn how to do custom escaping. 👍

Couple misc. thoughts:

1. We're already using label to describe the left-hand side of a badge, and I think that's a great term. I'm starting to think message would be a good name for the right-hand side. That pair of terms conveys our semantics really well. Our current JSON endpoint uses value, though I would rather change that, at some point, than continue to lock in a name that it's not obvious refers to the right-hand text. I mentioned this briefly at [RFC] New API for registering services #963 (comment) though we didn't end up discussing or choosing an alternative term.
2. For the URL, what about shortening from badge/static.svg to badge.svg? It harmonizes with the old one and I don't think would conflict.
3. Do we want to suggest users could choose between this and the existing static badge URL, at their preference?

[RedSparr0w]

Yes a main reason being users not needing to escape a mildly common character, think I saw something about it in an issue recently.
Edit: #815

1. Agreed, wasn't really set on value just couldn't think of a better alternative, though I think message works well.
2. I feel it shouldn't be top level, just to make it simpler to add/remove things later on (though not sure what sort of options may conflict) and to be similar to /badge/dynamic with all the options being parsed as params.
3. I don't think we could remove the old static badge as it is so widely used, but possibly change the default on the homepage.

[paulmelnikow]

2. I feel it shouldn't be top level, just to make it simpler to add/remove things later on (though not sure what sort of options may conflict) and to be similar to /badge/dynamic with all the options being parsed as params.

Could you elaborate? Do you mean to avoid conflicts with the current static badge?

3. I don't think we could remove the old static badge as it is so widely used, but possibly change the default on the homepage.

Agreed! So I suppose that's the question, whether to change the one we present and document on the homepage.

[RedSparr0w]

More to avoid conflicts with anything we might add to the /badge endpoint in the future,
I also feel /badge/static is a little more descriptive of what the badge is used for.
Kind of similar to the current /codeclimate/user/repo.svg badge, which doesn't quite explain what the badge is used for, just that it has something to do with codeclimate.

I think it should probably stay as it currently is.

/badge/label-message-blue.svg is a fairly easy format for most people to just quickly mockup compared to something like /badge/static.svg?label=label&message=message&colorscheme=blue which adds a lot of extra text.

A couple options could be:

• A note/link along the lines of "alternative static badge endpoint available"
  • open a pop-up which does the same as the current static badge generator
  • link to some info on the alternative
• A checkbox/select which changes between the 2 formats (with the current being the default).

[paulmelnikow]

I'm fine with that.

🤔

We could pick a format based on whether or not there are special characters in the badge…

Think it also makes sense to provide documentation for the alternate format.

[RedSparr0w]

I think it could be confusing for some users if we just auto decided the format to use based on the input.

Definitely needs some docs, but where should the documentation be located?
Maybe time to open up the GitHub wiki?

[paulmelnikow]

Ooooh, I forgot this was in flight! /cc @bkdotcom

Could we harmonize the scheme for this badge with the proposal in #1525?

I left some notes in #1525 (comment).

[paulmelnikow]

1. This is on my mind lately, though Move [StaticBadge] to own service & add test; also affects [gitter] #2284 needs to go in first.
2. We may also want to include a third static URL format like /badge/foo/bar/baz.svg which doesn't require dashes to be escaped.
3. I'd really like to get in the "badge json" service [badge-json] new "badge-json" service #1525, which plays really nicely with a tool like Runkit endpoints for building any kind of custom badge.

[paulmelnikow]

There are a lot of open PRs with code that needs reviewing. To help the maintainers identify the actionable PRs that are on a critical path, I'm marking this PR "stale." It's not dead, and can or will be picked up at some point.

Right now this one is blocked on #2284, though it will also need to be rewritten as a new-style static badge.

[RedSparr0w]

Just going to close this for now, may pick it up again later.