Add webhook sensor about argo-events HOT 3 CLOSED

We definitely need to support REST or http signals and triggers. In terms of the signals, do we need to consider which port to expose the endpoint on? Furthermore, to extend this feature to other applications on K8s and even outside K8s, these webhook signals should have a service that exposes them. Thoughts?

from argo-events.

Also, I understand the motivation behind including the trigger reference in the signal specification, but this shouldn't change the core concept that all signals must be resolved for any trigger to execute. I think what you intended this to be was for each of these signals' payload or content would act as input to the corresponding trigger. If this is the case, this should be generalized for not just webhook signals, this can be applicable for any type of signal that carries a message/artifact/content... (basically anything except time, in fact time seems to be a special case here).

from argo-events.

closing this from merged PR #15

from argo-events.