coverallsapp / github-action

Coveralls Github Action
https://coveralls.io
MIT License
467 stars 75 forks source link

Coveralls API outage suggests need for better testing and robustness #93

Open JonClayton opened 3 years ago

JonClayton commented 3 years ago

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

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.

pojeesaddam commented 3 years ago

The coveralls website (https://coveralls.io/) mentions that this is a planned maintenance but I could not find the schedule of this planned maintenance. Is there some information about when will this maintenance end? (which would hopefully fix 405 responses)

JonClayton commented 3 years ago

The assertion that it's planned is obviously false. A planned maintenance is by definition one that you announce in advance and have a plan that allows you to say when you expect it to be complete. I believe the correct term for this event, now almost 4 days long, is catastrophic outage.

prescottprue commented 2 years ago

Wanted to callout that there have still been periodic outages. Would it be possible to add a pass-on-failure input which would still pass the step if the upload to Coveralls fails?

mrexox commented 1 year ago

@prescottprue, do you mean marking the coverallsapp/github-action step as successful if pass-on-failure parameter is set to true even if the request failed?