Hook is a CLI tool for firing a collection of known webhooks for development.
Have you ever needed to build an app that consumes a new pull request webhook event from GitHub? Or maybe using Twilio's inbound SMS webhook. Sure there's some tooling that lets you replay those events once they've been made, but what if you don't want to jump through all of the hoops of creating a test repo, configuring the webhook to your dev server, and opening a new pull request.
That's the friction Hook aims to solve.
Webhooks are serialized to and from a basic YAML syntax with the intention of being human creatable and editable.
go get -u github.com/eddiezane/hookHooks can be fired locally by specifying the path:
hook fire webhooks/twilio/sms http://localhost:8080File suffixes are fuzzy matched - specifying a hook file foo will match foo, foo.yaml, or foo.yml
hook can be configured to read from remote Git repositories for hook data.
By default, hook comes installed with a default catalog of contributed hooks stored at https://github.com/eddiezane/hook-catalog.
hook fire @github/push http://localhost:8080Additional catalogs can be configured via the hook catalog subcommand.
Hook also has an HTTP server for recording new webhooks:
hook record --port 8080 path/to/new/webhook.ymlMultiple hooks received by the server will be stored in the same file as a multidoc yaml (separated by ---).
- Basic working POC
- Fire command
- Record command
- Initial release candidate
- Basic collection of webhooks to convey usability (Twilio, GitHub, ...)
- Don't use default http client
- Server error handling
- Server shutdown logic
- Better error handling in current commands
- Implement proper flags
- Add view command to view a webhook in it's YAML format
- Catalog logic
- Define spec for a catalog
- Download and lookup (tap) a new catalog
- Create default catalog as it's own GitHub repo
- Add automatic workflows to update webhooks.
- Template logic for webhooks (sub in vars)
- Web UI
MIT