The document docs/triggers_rules.md describes a trigger, then describes a rule. It will be good continue the doc on how to fire the trigger externally for example a webhook to finaly the concepts, or webhook -> rule (trigger (feed) -> action)
I expect this content and I am working on it for our project. Do you have an example?
@lfzCarlosC You can take a look at webhook.js.
webhook.js will register a webhook in github which will invoke a trigger in OpenWhisk.
I just want to plus one this. The API docs (https://github.com/openwhisk/openwhisk/blob/master/docs/reference.md#rest-api) document this, but the actual Trigger docs should as well.
AFAICS, fully handling github webhooks means:
X-GitHub-Event including the event type, or X-Hub-Signature for validating a custom secret)Because of this, I don't think exposing the trigger url as webhook as employed in the current /whisk.system/github is a practical approach. Rather one needs a web action in front as the actual webhook:
secret in the X-Hub-Signature (configured as default param on the action, for example).Also, this web action could then dispatch different event types from the webhook to different triggers, e.g. triggers github_push, github_issue... :
github -> web action (webhook) -> trigger (event type 1) -> rule 1 -> action 1
-> rule 2 -> action 2
-> trigger (event type 2) -> rule 3 -> action 3
...
Thoughts?
You are correct
here is a discussion, I name it “Web Trigger” where it doesn’t require coding it can be done via annotations
Most helpful comment
AFAICS, fully handling github webhooks means:
X-GitHub-Eventincluding the event type, orX-Hub-Signaturefor validating a custom secret)Because of this, I don't think exposing the trigger url as webhook as employed in the current /whisk.system/github is a practical approach. Rather one needs a web action in front as the actual webhook:
secretin theX-Hub-Signature(configured as default param on the action, for example).Also, this web action could then dispatch different event types from the webhook to different triggers, e.g. triggers
github_push,github_issue... :github -> web action (webhook) -> trigger (event type 1) -> rule 1 -> action 1
-> rule 2 -> action 2
-> trigger (event type 2) -> rule 3 -> action 3
...
Thoughts?