Coveralls API outage suggests need for better testing and robustness

We are in the midst of what is now a 40+ hour outage for the Coveralls API.

Consumers of this Github action receive a failed result that, at least in our usage of the action, blocks the workflow. At this point we face either removing the coveralls action from the workflow or forking it to patch is so that it doesn't fail for the current state (405 response).

Testing of the action is minimal. My suggestion would be that more tests be in place, especially around handling results from request that the user should not expect. In the current case, and given the nature of Coveralls, I'd suggest the result should be a warning that the API is unavailable but not a failure. The current behavior is akin to getting a 500 response from an API and an unintellible error message that the consumer cannot do anything to fix.

Start by reviewing the action's request handling and its existing tests, with particular attention to unexpected API results such as a 405 response. Done means adding coverage for unavailable or unexpected Coveralls responses and making the action report an understandable warning rather than blocking the workflow.