Add task for sending CloudEvents

[jlpettersson]

Expected Behavior

That there is a task for sending CloudEvents.

Typical use-cases:

• Notifying that a deployment occured.
• Notifying that a TaskRun failed e.g. failed unit-test.
• Notifying result from a Canary Analyze

This task would be on pair with the existing Slack an Telegram-tasks, but for CloudEvents.

Actual Behavior

I don't see this exists in Catalog

[ghost]

/kind feature

[bobcatfish]

Some context, one of the reasons this wasn't done already is that some of the CloudEvents logic in the CloudEvent PipelineResource happens in the controller vs. in the step containers like all the other PipelineResources. And one of the reasons for THAT was b/c in order to know if the currently executing Task has succeeded or failed, you had to wait until the entire thing completed (and failure would stop execution of any subsequent containers).

• @afrittoli if he wants to add any more context

[jlpettersson]

some of the CloudEvents logic in the CloudEvent PipelineResource happens in the controller vs. in the step containers like all the other PipelineResources. And one of the reasons for THAT was b/c in order to know if the currently executing Task has succeeded or failed, you had to wait until the entire thing completed (and failure would stop execution of any subsequent containers).

Right, I understand. Sounds like a mix of intern/technical events e.g. Kubernetes Event and "result reporting". Ah, right, it makes sense that a reporting-task will not execute if previous task failed, so such tasks must be places in finally:.

My intention here var purely business-oriented, e.g. letting the user know the result of a Canary-Analysis. In such case, I think this would provide value, but I agree that it would be hard to use for reporting errors. It can also be used for initiating things remote, or communicating with cloud services.

(This is just a wish for a Task - not anything I will start to work on at the moment).

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.