search

tcbyrd / probot-lambda

Test for running probot in AWS Lambda
25 stars 4 forks source link

Create sample event templates #2

Open bkeepers opened 7 years ago

bkeepers commented 7 years ago

It appears that Lambda has a bunch of built-in event templates that you can use to test your app. It'd be cool to create some of these for GitHub webhooks.

tcbyrd commented 7 years ago

I copied one of the requests and put the headers in the object to make it work:

testing-lambda

@bkeepers Any best practices on how to make this more "templatized"? To make sure it works, I've just been putting the response in a console.log in the plugin, but to actually test against live GitHub you'd need a full payload, right?

Also, do we need to obfuscate the X-GitHub-Delivery and X-Hub-Signature values?

// Here's the example payload  
{
  "headers": {
    "content-type": "application/json",
    "Expect": "",
    "User-Agent": "GitHub-Hookshot/96d0b6e",
    "X-GitHub-Delivery": "99999999999999999999", 
    "X-GitHub-Event": "issues",
    "X-Hub-Signature": "sha1=1f01f01f0f01f01f01f01f01f01f01f0"
  },
  "body": {
    "action": "opened",
    "issue": {...},
    "repository": {...},
    "installation": {
      "id": 32078
    }
  }
}
bkeepers commented 7 years ago

Any best practices on how to make this more "templatized"?

Sadly, no. This has actually been common problem with testing Probot plugins. There is so much data in the payload that it makes the surface area very large.

to actually test against live GitHub you'd need a full payload, right?

You really only need a few values, plus any other fields that your plugin is using. For example, if you're listening to the issues.opened event and want to use context.issue() to get the params to post something back on that issue, then here's the minimum payload needed:

{
  "headers": {
    "X-GitHub-Event": "issues",
  },
  "body": {
    "action": "opened",
    "issue": {"number": 999},
    "repository": {
      "owner": {"login": "username"},
      "name": "reponame"
    },
    "installation": {
      "id": 32078
    }
  }
}

One idea is to have Probot normalize the payloads into something easier to construct by hand, and allow it to receive either the full webhook from GitHub, or this normalized form. For example:

{
  "event": "issues.opened",
  "target": "username/reponame#999",
  "installation": 32078
}

Also, do we need to obfuscate the X-GitHub-Delivery and X-Hub-Signature values?

These aren't actually used by this lambda code right now. The lambda plugin should eventually verify X-Hub-Signature. X-GitHub-Delivery is just the unique ID of the payload so GitHub support can look it up if you report any issues with it.

tcbyrd commented 7 years ago

Thanks for the context around what's actually needed. That's super helpful.

I think a few minimal payload examples would be nice along with some documentation on how to set them up inside your own repo. I'll do some tests and put some example payloads in the repo. If we ever get support for Webhooks that can have their payloads defined by GraphQL, that might be the optimal solution. Then we'd just need a way to describe the schema that gets sent to Probot.

tcbyrd commented 6 years ago

Finally getting some cycles to look at this. AWS refreshed their UI for lambda and also added a feature to be able to save up to 10 test events in the console. This also lets you create new events from a template, so I can provide a few example webhooks and write some documentation on best practices: image