drone / go-scm

Package scm provides a unified interface to multiple source code management systems.
https://godoc.org/github.com/drone/go-scm/scm#pkg-examples
Other
174 stars 234 forks source link

Provide common abstraction for error messages coming from various systems #13

Open krainboltgreene opened 5 years ago

krainboltgreene commented 5 years ago

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 commented 5 years ago

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

bradrydzewski commented 5 years ago

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

bradrydzewski commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

bradrydzewski commented 5 years ago

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.