Open afrittoli opened 4 years ago
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:
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?
(Unless an action IS a notification, and "action" is a more generic name?)
Discussed with @wlynch, @dibyom and in WG, all agreeing that the best next step in this is https://github.com/tektoncd/pipeline/issues/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!)
Yeah, that sounds like a reasonable next step to me too.
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.
This is in our roadmap and @afrittoli has been making incremental progress on it (e.g. emitting more cloud events during execution)
/lifecycle frozen
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
Notifications
script
simplify writingsteps
). Define how notifications should look like based on the experience gathered in writing notifications through tasks