Actions and Notifications for Tekton

[afrittoli]

Expected Behavior

Tekton provides users with a mechanism to run actions on events, and, as a special case, send notifications, as designed in https://docs.google.com/document/d/1ehhGngn2ulnjYX0HUxSyhQGAvcbabSa27UZs3RvZWwU/edit#

Actual Behavior

This Epic defines incremental steps towards supporting notifications.

Given the recent discussions about PipelineResources, I think it will make sense to first implement a generic actions framework, and to implement notifications as a specialized case of that, which may or may not require a dedicated CRD.

High level implementation plan

Refresh the design document and discuss in the WG.

Framework for Actions

1. Extend the Task and Pipeline API to allow specifying actions on event
2. Implement a way for Task to receive information about the trigger. We could extend the definition of Task to include some default optional parameters for use annotations.
3. Implementation of the TaskRun/PipelineRun controller changes where actions can run generic Tasks on events
4. Extend the TaskRun and PipelineRun API to allow specifying notifications on *Run resources
5. Extend the TaskRun/PipelineRun controller to allow getting actions from *Run resources. To be defined: do we merge or override actions?

Notifications

1. Try to implement different notifications using actions
2. Notifications should be simple to use. They should embed common boilerplate code to simplify the way they are defined (similar to how script simplify writing steps). Define how notifications should look like based on the experience gathered in writing notifications through tasks
3. Decide if we need an extra CRD specific to notifications
4. Extend the Task(Run)/Pipeline(Run) API to support notifications (which triggers Tasks or the Notification CRD if that is needed)
5. Define a CRD to specify global notification policies
6. Extend the TaskRun/PipelineRun controller to be able to merge global notification policies with those defined on the task / pipeline

[bobcatfish]

Question: what does "Action" mean in this context? Is the idea of an action meant to be the combination of a trigger + the thing to run in response to the trigger? Would the "Action" being executed be a PipelineRun/TaskRun or something else?

If the idea is to link an executing Pipeline/Task with other Pipelines/Tasks via events then I think that this could be generalized a step further into a way of expressing groupings of Tasks/Pipelines and events, what do you think? (A similar concept has recently been discussed at Google and has been temporarily referred to by the terrifyingly vague name "workflow")

---

Assuming the above is an accurate representation of where this is going, I'm not convinced that we need the above action/workflow framework for notifications - I can see a notification being something added to a Pipeline directly, not something that is expressed in a linking between Pipelines/Tasks and events.

---

Trying to summarize how I'm seeing this:

1. Notifications: in a Pipeline, expressing that you want to do something (probably run a Task) in some state (e.g. always, on failure - probably via Design: Failure Strategy for TaskRuns in a PipelineRun #1684 )
2. Actions in this proposal: an event, which needs to be emitted ( Optionally emit events during execution #2082 ), then consumed by something (triggers?) triggering an action to happen (taskrun? pipelinerun? something else)
3. Workflow: expressing a linkage of event -> trigger -> PipelineRun which itself may emit events which -> trigger -> PipelineRun etc. in a graph of it's own

Personally I think that if we want to go in the direction of 3, I'm not sure how much use we get from just 2?

[bobcatfish]

(Unless an action IS a notification, and "action" is a more generic name?)

[bobcatfish]

Discussed with @wlynch, @dibyom and in WG, all agreeing that the best next step in this is #2082, which allows us to emit events during the lifecycle of execution and then execute something as a result, greatly simplifying @afrittoli 's work in https://github.com/tektoncd/plumbing/blob/45b8b6f9f0bf10bf1cf462ee37597d1b44524fd8/tekton/ci/docs/ci-setup.svg (and this might make it so we no longer need the CloudEvent PipelineResource as well, tho we may still want a Task version!)

[afrittoli]

Yeah, that sounds like a reasonable next step to me too.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[bobcatfish]

This is in our roadmap and @afrittoli has been making incremental progress on it (e.g. emitting more cloud events during execution)

/lifecycle frozen