Create sample event templates #2

Activity

1. tcbyrd commented on Jul 29, 2017

   

   tcbyrd

   on Jul 29, 2017

   Owner

   More actions

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

   

   @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
       }
     }
   }
2. bkeepers commented on Aug 1, 2017

   

   bkeepers

   on Aug 1, 2017

   Author

   More actions

   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.
3. tcbyrd commented on Aug 1, 2017

   

   tcbyrd

   on Aug 1, 2017

   Owner

   More actions

   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.
4. tcbyrd commented on Oct 4, 2017

   

   tcbyrd

   on Oct 4, 2017

   Owner

   More actions

   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: