Add [PingPong] Service

[bluecap-se]

Adds two new badges for PingPong Status Page service:

• Uptime (last 30 days)
  
• Status
  

[shields-ci]

	Messages
📖	✨ Thanks for your contribution to Shields, @bluecap-se!

Generated by 🚫 dangerJS against 1aa731f

[lgtm-com]

This pull request introduces 2 alerts when merging 4515614 into 27951e9 - view on LGTM.com

new alerts:

• 2 for Unused variable, import, function or class

[calebcartwright]

hi, thanks for the PR! Could you take a look and address the failing CI checks?

They seem to be linter related, and you should be able to reproduce locally via npm run lint

[bluecap-se]

Thanks for your feedback @calebcartwright! Please have another look after the fixes.

[calebcartwright]

Can you tell us a little more about the API token? I assume that it's absolutely necessary in order to fetch the data?

Can this token have it's permissions/auth. scoped to a read-only mode, or does it inherently provide other permissions as well?

[bluecap-se]

Of course. The API token is a public read-only token that's specific for status/uptime badges, making it safe for public sharing. It's required to the fetch the data, otherwise the backend returns 404. It has no other permissions and is separate from the API key with full permissions that's used for the REST API.

[calebcartwright]

Thanks for the PR and additional info! It seems reasonable to incorporate these badges, though I think we've got an opportunity to simplify the implementation somewhat by reusing some standard Shields helpers.

Have left specific details inline

[calebcartwright]

The approach taken here is basically just using us as a passthrough for whatever values the upstream provider happens to set, which isn't how we utilize values from the upstream endpoints.

A core goal for the Shields project is to provide consistency and stay aligned to our badge specification, and that's not really something we can be sure we're adhering to if we let an upstream service specify core badge attributes like the message and color.

Instead, what we do is inspect the value(s) and only the value(s) from the response we get from the upstream service in order to figure out what we should set attributes like the message and color of our badges to be. In many cases for common categories of badges we also have utility/helper functions that handle common concerns, like rendering and query params, which helps us both ensure consistency across our badge offerings and simplifies the codebase.

I think there's a great opportunity to do that here, and I'd suggest taking a look at some of the service classes for our other badges in the monitoring category, such as nodeping, as a frame of reference

[bluecap-se]

Very good points. In the update, I've referenced uptimerobot as it seemed to match this use case; nodeping example doesn't have all status types (issues, maintenance being the case here) but it pointed me in the right direction - thanks for that! If there's a helper function in Shields that supports all status types, I'd be happy to apply it here.

[calebcartwright]

Thank you for the changes and apologies for the extended delay on the second review; this one fell off the radar!

This is in much better state now, though with a few comparatively minor things that'll need to be adjusted before merging

[calebcartwright]

Updates look good thanks! Could you rebase on master? We have the up-to-date branch gate enabled so will need to get this in sync with master before it can be merged, but should be good to go afterwards

[PyvesB]

Great to see this work completed, thanks @bluecap-se and @calebcartwright for your work! :)

[calebcartwright]

Oops, looks like another PR got merged inbetween and this is out of date again. Will require another rebase on your end sorry. IIRC you should also be able to check the box to allow maintainers to update the PR which would allow us to sync the branches for you and make it a bit easier to merge

[bluecap-se]

@calebcartwright The branch should be updated again. The option to allow maintainers doesn't seem to exist on this PR.

[PyvesB]

Strange that the option doesn't exist on this PR. Let's get this merged before it's too late again! :)

[PyvesB]

These badges are now live! 🍾

For example: https://img.shields.io/pingpong/status/sp_2e80bc00b6054faeb2b87e2464be337e

If you've got a Twitter handle @bluecap-se , I can post a little something.

[bluecap-se]

@calebcartwright @PyvesB Great to see this live, thanks for all your feedback and assistance! 🚀

Our Twitter handle is @pingpong_status

As the creator of PingPong status pages I'd like to present our offering to all open source projects: free Pro plan. If this sounds interesting for Shields, start by creating a Pro account and then ping us to activate the open source offer.

[PyvesB]

There you go, I sent a little something: https://twitter.com/Shields_io/status/1392012310940692482

Thanks for making us aware of the offering for open-source projects. For now I think we're good on that side, we already have an integration with one of your competitors, UptimeRobot - though there's a config problem at the moment that I'm working on fixing! :)

[bluecap-se]

Sorry to see https://status.shields.io still being down, let us at PingPong know if we can assist in any way.