Open JeromeJu opened 1 year ago
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
with a justification.
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
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
with a justification.
Mark the issue as fresh with /remove-lifecycle rotten
with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen
with a justification.
/close
Send feedback to tektoncd/plumbing.
Thanks for the catch @afrittoli at https://github.com/tektoncd/pipeline/pull/6444#issuecomment-1594816511.
Now that we are migrating v1 to the apiVersion and for the CloudEventsData, the API version is actually not specified, see https://tekton.dev/docs/pipelines/events/, but there are changes between v1 and v1beta1, so we should warn users about that.
For the current being, as a workaround the TektonCloudEventData is being converted back to v1beta1 for emitting cloudEvents. Eventually, we would want to update the version number on the event type (e.g. dev.tekton.event.taskrun.started.v1) - switching those to v2.
Also, it would be nice to have a config flag that allows selecting which version of events to send, to start sending v2 but give an option to continue using v1 and deprecate v1.
/kind misc