Hi folks!
I've been working with CDEvents, specifically "Core Events", and would like to propose extending taskRun predicates to have a queued predicate.
Some consumers want to know not only that a task has started or finished, but that it's been planned to start in the future.
The simplest use case is displaying upcoming tasks on a dashboard, so users see not just completed and in-progress work but also what's coming next. There are more involved infrastructure use cases as well.
Based on my experience with specification, I noticed that the only predicate that indicates something that would happen in the future is queued. Moreover, pipelineRun already has one, so it might make sense to add one to taskRun to have symmetric sets of predicates.
It also makes sense because the pipeline run can already be started, but some task takes lots of time/compute to complete, so other tasks are "queued," and event consumers are notified about it.
Similar to pipelineRun, we could say:
Adopters can choose to ignore these events if they don't apply to their use cases.
I've also noticed that testSuiteRun from "Testing Events" already has a queued predicate. Since a task could represent a test run, IIUC the specification, having this predicate for taskRun seems consistent.
Let me know what the community thinks about it!
P.S. I am happy to elaborate on my motivation via virtual catch-up according to the cdEvents calendar if needed. Just assumed that the proposal is small enough to discuss here :)
Hi folks!
I've been working with CDEvents, specifically "Core Events", and would like to propose extending
taskRunpredicates to have aqueuedpredicate.Some consumers want to know not only that a task has started or finished, but that it's been planned to start in the future.
The simplest use case is displaying upcoming tasks on a dashboard, so users see not just completed and in-progress work but also what's coming next. There are more involved infrastructure use cases as well.
Based on my experience with specification, I noticed that the only predicate that indicates something that would happen in the future is
queued. Moreover,pipelineRunalready has one, so it might make sense to add one totaskRunto have symmetric sets of predicates.It also makes sense because the pipeline run can already be started, but some task takes lots of time/compute to complete, so other tasks are "queued," and event consumers are notified about it.
Similar to
pipelineRun, we could say:I've also noticed that
testSuiteRunfrom "Testing Events" already has aqueuedpredicate. Since a task could represent a test run, IIUC the specification, having this predicate fortaskRunseems consistent.Let me know what the community thinks about it!
P.S. I am happy to elaborate on my motivation via virtual catch-up according to the cdEvents calendar if needed. Just assumed that the proposal is small enough to discuss here :)