I actually might not have written mine if this had been around. I intend to play with this as we want to start handling webhooks from other services and I'm not really interested in growing the scope of Hookah.
Just Curious: Whats the appeal here? Why did you all decide to work on this? What were (if at all) you using before this was made by you?
Now we can define where things route simply by where they go in the hierarchy and it's wonderfully simple to use.
It was a fairly simple undertaking in Go, and we've been very happy with it overall.
Edit: if you aren't married to configuration in a file, you could even do hosted JS or Lua functions kinda like a serverless environment
JSON is definitely nice for the time vs. effort balance; you've effectively got the users writing AST directly. And, building tooling to make it easier to write and manage is good.
In any case, the project/service is really cool!
As an example: We worked on something similar for a school project in Python, where you would simply write classes for each things, which would then create a JSON file.
In your case, might not be what you want if you do not want to tie to a single language though.
You can take what you've said, replace "JSON" with "XML" and you've got an explanation for Maven and all the other Java tools with a ridiculous amount of logic shoved into some generic markup format that was never intended for it. History has shown that it sucks to deal with. XML was the hot, "obvious", "everybody knows it", format of its day. I agree that JSON is, in most uses, a hell of a lot better, but, like XML it is a terrible place to be defining logic.
It really needs to be something that is actually designed to encode logic, not a data structure format. A custom DSL is a decent, and probably very easy (for users) idea, but if the author was really not interested in the design and debugging of such a thing then you could use LUA or some other embedded language.
I think I even mentioned embedded JS or Lua in some other comment.
It is also possible to wait for the command to finish and return the response as part of the HTTP response, or just return 200 Ok and run the script in the background.
My very first job as a professional programmer, back en 1994, was writing a CGI in plain C. Good old times.
Command to run should be just called command. And trigger rule can be just trigger no?
Maybe personal preference.
Verbosity is sometimes good but in the context of this.. Where all you are doing is giving commands, giving them arguments... there are not so many things here that can lead to confusion.
If you had multiple arg fields I understand.
Again, preference :)
I'm also a bit concerned about the authentication story. You can require the sender to provide a hash signature, but you have to specify the secret in plain text in the webhook config file. That's not best practice. Better would be ldap or Kerberos integration. And again, there should be secure defaults.
Webhook can wait for the script execution and return the stdout & stderr as response.