Restrict assert with apiVersion/kind to only relevant objects

[gpaul]

What would you like to be added:

When I specify an assert step and specify the apiVersion and kind fields on my assert object, then my object should only be compared against objects of the same kind.

For example, the following assert failure output is noisy and pretty useless:

                 apiVersion: v1
                +count: 1
                +eventTime: null
                +firstTimestamp: "2020-05-11T23:12:59Z"
                 involvedObject:
                -  apiVersion: tekton.dev/v1alpha1
                -  kind: PipelineRun
                +  apiVersion: v1
                +  fieldPath: spec.containers{git-daemon}
                +  kind: Pod
                +  name: git-daemon-f54ff8cb9-x7t6x
                +  namespace: kudo-test-capital-lionfish
                +  resourceVersion: "2677"
                +  uid: a3ebd99c-45a8-45bd-9f25-2cc3f8e7b5af

Note that involvedObject expects a tekton.dev/v1alpha1.PipelineRun:

                -  apiVersion: tekton.dev/v1alpha1
                -  kind: PipelineRun

but is compared to a v1.Pod:

                +  apiVersion: v1
                +  kind: Pod

I don't think there are valid scenarios where this could be valuable information.

Why is this needed:

The log output is extremely verbose when there are many objects and an assert fails.

[kensipe]

@gpaul I don't believe I understand enough context here... could you provide a simple setup.yaml and an assert.yaml with an expectation of what should pass and what should fail? or explain a bit more please?

also... great to hear from you!!

[gpaul]

Hey :-)

Sure, so I have the following assert.yaml:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  labels:
    repository-ref: dispatch
spec:
  resources:
  - name: git
  serviceAccountName: github-webhook
  timeout: 1h0m0s
status:
  conditions:
  - message: "Tasks Completed: 2, Skipped: 0"
    reason: Succeeded
    status: "True"
    type: Succeeded

That assertion failed in my test. Which is fine. Now I want to debug it.

In the kuttl output, I see:

...
            case.go:155: resource Task:kudo-test-driving-lobster/: .spec.resources: key is missing from map
            case.go:155: no resources matched of kind: tekton.dev/v1beta1, Kind=TaskRun
            case.go:155: --- Event:kudo-test-driving-lobster/
                +++ Event:kudo-test-driving-lobster/dispatch-login-mj9rc.1615258a32213038
                @@ -1,13 +1,24 @@
                 apiVersion: v1
                +count: 1
                +eventTime: null
                +firstTimestamp: "2020-06-03T21:21:58Z"
                 involvedObject:
                -  apiVersion: tekton.dev/v1alpha1
                -  kind: PipelineRun
                +  apiVersion: v1
                +  kind: Pod
                +  name: dispatch-login-mj9rc
                +  namespace: kudo-test-driving-lobster
                +  resourceVersion: "3899"
                +  uid: 52fb966e-60ef-4a0a-bf93-bed53ddf9b50
                 kind: Event
                -message: 'Tasks Completed: 2, Skipped: 0'
                +lastTimestamp: "2020-06-03T21:21:58Z"
                +message: Successfully assigned kudo-test-driving-lobster/dispatch-login-mj9rc to kind-control-plane
                 metadata:
                +  name: dispatch-login-mj9rc.1615258a32213038
                   namespace: kudo-test-driving-lobster
                -reason: Succeeded
                +reason: Scheduled
                +reportingComponent: ""
                +reportingInstance: ""
                 source:
                -  component: pipeline-controller
                +  component: default-scheduler
                 type: Normal

Notice that the error output shows a comparison between the tekton.dev/v1beta1.PipelineRun, which is the object in my assert.yaml, and a v1.Pod.

This ticket is about not printing the comparison between the expected object with objects of a different apiVersion and Kind. If the user sets a specific apiVersion/kind in the assert, odds are they're not interested in or surprised by the fact that the asserted object doesn't match objects of a completely different kind.

[porridge]

I believe this was fixed by #488