Extend webhook notifications with build status #5621
Conversation
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
We should look at this. It seems useful :) Sorry it's been sitting. |
readthedocs/projects/tasks.py
Outdated
| @@ -1353,19 +1366,20 @@ def _manage_imported_files(version, path, commit): | |||
|
|
|||
|
|
|||
| @app.task(queue='web') | |||
| def send_notifications(version_pk, build_pk): | |||
| def send_notifications(version_pk, build_pk, send_email=True): | |||
There was a problem hiding this comment.
This should probably default to False, so that we don't accidentally send users email. Then we can just update the places where we do want to send email.
| @@ -1440,6 +1454,8 @@ def webhook_notification(version, build, hook_url): | |||
| 'slug': project.slug, | |||
| 'build': { | |||
| 'id': build.id, | |||
| 'commit': build.commit, | |||
| 'state': build.state, | |||
There was a problem hiding this comment.
We should define what data we send here in the docs as part of this PR, it will be much more useful to users that way :)
|
@ericholscher this needs a bit of work and polishing. We will use the Github Status API to send notifications also as a part of the PR Builder. So, I think we should start working on this again when we get to that point to implement it in a better way if possible. |
saadmk11
force-pushed
the
extend-webhook-notification
branch
from
45f6945 to
6767b16
Compare
|
Now we can send webhook notifications when the build has triggered and when the build has finished. {
"name": "Read the Docs",
"slug": "rtd",
"build": {
"id": 6321373,
"commit": "e8dd17a3f1627dd206d721e4be08ae6766fda40",
"state": "finished",
"success": false,
"date": "2017-02-15 20:35:54"
}
}But One issue is when the build has triggered we don't have the |
saadmk11
removed
the
PR: work in progress
|
I don't think this is blocked anymore so we can remove blocked label. :) |
|
Removing blocked as this is not blocked anymore |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
There was a problem hiding this comment.
I think this is useful.
There is one thing that I'm not sure how to handle. We were sending a webhook notification only when the builds failed. So, people were taking an action in that case --now we are going to start sending webhook notification on start and finish (success and fail). This could cause a lot of problems if people is only expecting to receive the webhook on failures.
I think if we want to make this change to happen, we need a way to keep the current behavior and add something new for the Hook objects where the user can decide what kind of webhooks wants to receive.
Thanks for the review! 👍 Users will get the usual notifications as before but it will include some extra ones. Not sure if that will break things :). If we want we can add some kind of option to let users select this. Something like check boxes with
|
If we are sending the notifications as before, I'm 👍 with this PR. I wasn't aware that we were sending webhook notification on trigger, success and failed. Thanks for clarifying this. There is no need to manually select what status you want to receive notifications. I wanted that only if we were changing the behavior. |
@humitos Actually I meant to say that we were sending webhook notifications on |
I did not add support for build status API of GitHub, Gitlab etc. as those need a different approach than what we currently have. We need to send theshaof the commit with the URL as the their docs Suggests.ie:POST /repos/:owner/:repo/statuses/:shaGithub Build Status API Docs Gitlab also has a similar implementation.
We need some
Design Decisionsfor adding support for this. We can add some kind of module to handle the status APIs.We are sending PR Build Status reports using GitHub Status API #5865 and planning to extend to other providers.
closes #2251