Provide common abstraction for error messages coming from various systems

[krainboltgreene]

See also: https://discourse.drone.io/t/status-500-issue-at-cloud-drone-io-for-push-webhooks-on-github/3266

Here's the logs:

{"commit":"eea3eef8056c9c1bdf69537a1c1ac71a93946c2c","error":"Not Found","event":"push","level":"warning","msg":"trigger: cannot find yaml","ref":"refs/heads/feature/SR-777","repo":"core/second-reef-api","time":"2019-02-13T00:45:24Z"}

[krainboltgreene]

In reality the http status should be 424 and the message should be "respository does not have a drone configuration file".

[bradrydzewski]

I think I need some context with this issue. The original discourse thread was not very clear

[bradrydzewski]

ah ok, is this issue a suggestion to change the response code to 424 when the yaml does not exist? sorry, I did not understand at first.

[krainboltgreene]

Well, if I get only one change in it's that the HTTP Body contains information that is very misleading and should reflect the actual issue.

But while I'm here I suggest that the status code could be more semantically correct than 500 by using 424.

[krainboltgreene]

To replicate this by the way setup a drone ci, activate a project with out a configuration file, make a commit.

[bradrydzewski]

The 'Not Found' error message is coming from GitHub, not from Drone. This is one of many error messages that could be returned from GitHub, so returning a 424 may not always be accurate. We also integrate with Gogs, Gitea, Bitbucket, Gitlab which may use different text to indicate the file does not exist. Perhaps we could try to translate the various error payloads from the different systems to abstract the errors and provide more meaningful responses.

I am going to send this over to go-scm where we handle the abstractions.