-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cloud Events for Runs #3862
Comments
I like the idea of basic cloudevents for Run start/success/failure that everybody gets out of the box, and documentation/samples for Custom Task authors to add their own if they want. The pipelines controller doesn't currently do anything with Runs, I'm not even sure it has a no-op reconciler for them, so if we decide we want to support this we'd add one and do it there. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
/remove lifecycle/rotten |
remove-lifecycle rotten |
/lifecycle frozen |
Custom tasks can be part of a pipeline now - in that scenario we could send cloud events on behalf of the Run controller. |
moved this to milestone for v0.31 |
/assign @afrittoli |
The My proposal here would be to implement this in the external controller instead. This would then be implemented once the external controller replaced the inbuilt one for sending events. @pritidesai @vdemeester @jerop thoughts? |
I tend to agree on the external controller 👼🏼 |
thanks @afrittoli! Yup implementing as part of an external controller sounds reasonable. This can give freedom to the external controller in designing the events based on their requirements. |
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
/cc @lbernick |
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Add the definitions for new CloudEvents for Runs. The events are not sent yet. The event types are documented and the cloudevent package supports creating events for Runs. Partially addresses #3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes tektoncd#3862 Signed-off-by: Andrea Frittoli <[email protected]>
Emit CloudEvents for Runs. This is achieved by: - add a new read-only controller for Runs - emit CloudEvents only (no k8s events) on every reconcile of a Run - use an ephemeral cache to store sent events across reconcile runs. This is required because since the Runs controller only observes Runs, it does not have the context to know what was changed in the Run and though if a new event is required. The ephemeral cache logic is largely taken from the same functionality implemented in tektoncd/experimental/cloudevents Fixes #3862 Signed-off-by: Andrea Frittoli <[email protected]>
Feature request
Cloud events should be sent Runs.
It needs to be identified whether we want this to be a responsibility of the custom task controllers, the pipeline controller or a dedicated one.
Use case
We support cloud events for taskruns and pipelineruns, we should support them for runs too.
The text was updated successfully, but these errors were encountered: