Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Webhooks/events for integration with external services #822

Open
knrafto opened this issue Aug 27, 2016 · 3 comments
Open

Webhooks/events for integration with external services #822

knrafto opened this issue Aug 27, 2016 · 3 comments

Comments

@knrafto
Copy link
Contributor

knrafto commented Aug 27, 2016

We should be able to configure (on a per-course or per-assignment basis) actions that will be triggered when certain events happen, such as receiving a new backup. This could either send an HTTP POST request to a URL, or call one of our "extensions" that can be used for this purpose. This will allow cleaner separation of concerns, and allow staff to swap in their own custom autograder instead of using ours.

Potential use cases:

  • Running the autograder for each new submission
  • Autograding all submissions
  • Running moss on all submissions
  • Uploading to Canvas API on each new score
  • Notifying an online cheating detection system with each new backup
  • Updating hog contest rankings for each new submission

We should look at the GitHub webhooks docs for inspiration.

@Sumukh
Copy link
Member

Sumukh commented Oct 11, 2016

Here's an implementation:

  • There are a certain set of events that we support (New Backup, New Submission, New Score, New Group)
  • There'll be a webhook table that will allow us to create webhooks specific to a course or specific to an assignment.
  • The route responsible for creating the new object will also be responsible for sending the webhook.
    • The better, but more annoying alternative is to have commit hooks on the SQLAlchemy models
  • The actual sending of the webhook will be a deferred task (with its own queue).
    • It should be delayed because sending the webhooks should not ever delay the original task.

@knrafto
Copy link
Contributor Author

knrafto commented Oct 12, 2016

  • +1 on sending webhooks being a deferred task. We should also retry delivery, and show which delivery attempts have failed.
  • The body of the webhook request should contain the JSON representation of the new object.

Here's a possible schema:

class Webhook(Model):
    event_type  # enum of possible event types
    course_id
    assignment_id  # nullable. if null, applies to entire course.
    webhook_url  # URL to POST to
    secret_token  # security token to include with webhook request

I'm not sure how this would handle our own integrations (e.g. bCourses). We could just fill in an internal URL (e.g. the URL is https://okpy.org/...)

@Sumukh Sumukh added this to the Spring 2016 milestone Dec 24, 2016
@Sumukh
Copy link
Member

Sumukh commented Dec 24, 2016

A course has requested a basic version of this (trigger a webhook upon submission).

@Sumukh Sumukh self-assigned this Dec 24, 2016
@Sumukh Sumukh removed their assignment Apr 18, 2017
@Sumukh Sumukh removed this from the Spring 2016 milestone Apr 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants