You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The build controller should emit Kubernetes events for BuildRun objects. These should reflect the important state transitions for the BuildRun's lifecycle - namely if it started, if it succeeded, or if it failed.
The set of events we emit to the cluster can be the building blocks for events that can be emitted outside the cluster, through specifications like CloudEvents.
/kind feature
The text was updated successfully, but these errors were encountered:
I wasn't sure if adding events to the controller by itself warranted a SHP, since my initial intent was to not expose an API or configuration to tune the emitted events. In my experience controllers don't allow events to be configurable - they fire "Normal" events to provide object lifecycle information, and "Warning" events if something went wrong.
Kubernetes events are also considered ephemeral in nature - I believe by default events are reaped/deleted by the cluster after one hour.
Based on the feedback in #824 - we should discuss in a SHIP what events we want to emit, and consider how Shiwpright events may overlap/conflict with Tekton events.
Idea:
The build controller should emit Kubernetes events for BuildRun objects. These should reflect the important state transitions for the BuildRun's lifecycle - namely if it started, if it succeeded, or if it failed.
The set of events we emit to the cluster can be the building blocks for events that can be emitted outside the cluster, through specifications like CloudEvents.
/kind feature
The text was updated successfully, but these errors were encountered: