Add concurrent hook executor in /postreceive view_func

[tvytlx]

When the client sends requests, the process on the server side will block until all hook functions finished, so the client won't get timely respond (sometimes we run long shell scripts in the hook to deploy) and can't figure out what happen on the server either. In fact, we don't need the respond data, right? why not let it return in time.

Maybe we need further discussion.

[fophillips]

This looks good. Have you been using it successfully? Might try running this on our production webhooks to see if we have any problems before merging.

[tvytlx]

@fophillips Yes, It works well in my project.

[fophillips]

@tvytlx have you tried passing threaded=True or processes=2 to app.run instead? I think Werkzeug will support this out of the box.

[tvytlx]

@fophillipsthreaded or processes is set to serve multiple clients(requests), but the problem here is the single request timeout. Though passing threaded=True, the request wait in a new thread, will still timeout.

[josegonzalez]

@fophillips any luck trying this out? Just curious if we should wait till this is merged or not :)

[fophillips]

The problem I have with this is if the hook fails there is no feedback 😒

[fophillips]

Could we make it optional instead? Add another decorator maybe for @webhook.async_hook?

[alexchamberlain]

I tend to agree with @fophillips; I'm a little concerned that this obscures the normal case that you want feedback if the hook fails. I could get on board with a second decorator, though.

[tvytlx]

@alexchamberlain 👌