Take advantage of kmeta.OwnerRefable.

[mattmoor]

Changes

I noticed that the tekton controller.go files were inconsistently using controller.HandleAll (cosmetic), but also that several of the impl.EnqueueControllerOf lines in the PipelineRun controller weren't filtering on the kind of the owner (can cause unnecessary reconciliation).

For the latter, we also introduced a nice new helper controller.FilterController(&v1beta1.TaskRun) that takes advantage of kmeta.OwnerRefable to filter on the GVK in the owner reference.

This spiraled a bit because it turns out Tekton wasn't taking advantage of kmeta.OwnerRefable or kmeta.NewControllerRef! So the majority of the churn in this change is:

• GetOwnerReference -> GetGroupVersionKind (implements kmeta.OwnerRefable)
• foo.GetOwnerReference() -> *kmeta.NewControllerRef(foo)

As some background, our kmeta.NewControllerRef API was modeled after this from API machinery: https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#NewControllerRef

We added our own variant to drop the tedious GVK requirement, since the first argument should be sufficient (thus kmeta.OwnerRefable).

/kind cleanup

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Docs included if any changes are user facing
• Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Release notes block below has been filled in or deleted (only if no user facing changes)

Release Notes

NONE

cc @dlorenc @imjasonh @vdemeester @afrittoli

[imjasonh]

/lgtm

Thanks for this cleanup!

For my own edification: Can you clarify what kinds of unnecessary reconciliations we might have experienced previously, that will be avoided with this new version?

[mattmoor]

For my own edification: Can you clarify what kinds of unnecessary reconciliations we might have experienced previously, that will be avoided with this new version?

Absolutely. So one of the byproducts of how this was written before (unfiltered) the EnqueueControllerOf code would look at the owner reference and queue namespace/name key regardless of whether that key's type matches the controller's "primary key" type or not.

So if I have a MatrixRun resource named bob, which stamps out TaskRun or Run resources, then the PipelineRun controller will observe changes to these and queue namespace/bob. Likely this means log spam because there isn't a namespace/bob PipelineRun resource, but if there is, then it also means extra work is done.

controller.FilterController(kmeta.OwnerRefable) and kmeta.NewControllerRef(kmeta.OwnerRefable) are sort of duals. One sets up the owner reference, and the other filters things that aren't owned.

[dlorenc]

/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dlorenc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dlorenc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment