Move all defaulting to a (/the) common place

[nikhil-thomas]

This issue is to make sure that all defaulting logic is moved to the location where all the other defaulting logic lives. For example: The following items could be something we can move to the here

-https://github.com/tektoncd/operator/blob/eb53caf21f0eb83f7820ccd42accfa29de5caf1e/pkg/reconciler/openshift/tektontrigger/extension.go#L65

[vdemeester]

I am not sure to see the value, mainly because webhooks are not the greatest to manage. I think, the "problem" here is that similar defaulting happens in different places, whereas it should be happening at the same place. Most likely, this means the code you link should be moved to https://github.com/tektoncd/operator/blob/main/pkg/apis/operator/v1alpha1/tektontrigger_defaults.go, so that's it can be called by the webhook and the reconciler, with the same behavior.

[nikhil-thomas]

it should be happening at the same place.

definitely a better way to say it. 🧑‍💻 👍

so that's it can be called by the webhook and the reconciler, with the same behavior.  ➕ 💯

i shall update the issue descriptio (~Move all defaulting to webhook~ Move all defaulting to a (/the) common place)

[savitaashture]

This issue is to make sure that all defaulting logic is moved to the location where all the other defaulting logic lives. For example: The following items could be something we can move to the here

-https://github.com/tektoncd/operator/blob/eb53caf21f0eb83f7820ccd42accfa29de5caf1e/pkg/reconciler/openshift/tektontrigger/extension.go#L65

@nikhil-thomas I think we have some default values which are platform specific so should we keep them as it is ?

[nikhil-thomas]

we shall keep them as it is and where they are 🧑‍💻. As vdmeester mentioned irrespective of what the defaults are and where they are written in the codebase, this issue's objective is to make sure that the defaulting is done by the webhook, as part of admission control.

In other words, we want to eliminate any instance of "setDefaults then explicitly update instance" practices, if there are any in the codebase.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.