Update list to filter resources using label selectors

[jtucci]

What this PR does / why we need it:

Currently, If no name is specified in an assert resource, the CheckResource and CheckResourceAbsent will find all resources of with the same gvk and assert against one of the resources returned in the list. This PR is a proposal to enhance how resources are matched by filtering the resources by any included labels in the case where no name is specified.

Example Use Case / Scenario
We are using KUTTL for e2e testing for the crossplane compositions we are developing. The resources we are asserting against (managed resources) are created in a similar way to pods being created by a replica set, in that the metadata.name will contain a random uuid. In the case where there are several resources of the same gvk, we are unable to guarantee that the correct resource is asserted against which causes unexpected failures within the tests. The only other workaround is running script commands such as:

test "$(kubectl get virtualnetworkpeering.network.azure.upbound.io -o json | jq -r '.items[] |
      select(.metadata.labels.name=="virtual-network-peering-to-target") |
      .metadata.annotations["crossplane.io/external-name"]')" = "to-shoot--test--test-dev-us"`

This is very tedious (we have to do this for every field in the resource(s)). It also makes understanding any test failures difficult since no diff is shown, just that a command failed.

This enhancement would give us the ability to instead assert against the yaml definition of the resource like any other test would because we can specify unique labels to identify the resources. For example, the following two resources with no name and the same gvk would be asserted against the correct resource with the matching labels

---
apiVersion: network.azure.upbound.io/v1beta1
kind: VirtualNetworkPeering
metadata:
  annotations:
    crossplane.io/external-name: to-shoot--test--test-dev-us
  labels:
    name: virtual-network-peering-to-target
spec:
  deletionPolicy: Delete
  forProvider:
    remoteVirtualNetworkId: >-
      /subscriptions/xxxxxxxxx/resourceGroups/shoot--test--test-dev-us/providers/Microsoft.Network/virtualNetworks/shoot--test--test-dev-us
    resourceGroupNameSelector:
      matchControllerRef: true
      policy:
        resolution: Required
        resolve: Always
    virtualNetworkNameSelector:
      matchControllerRef: true
      policy:
        resolution: Required
        resolve: Always
---
apiVersion: network.azure.upbound.io/v1beta1
kind: VirtualNetworkPeering
metadata:
  annotations:
    crossplane.io/composition-resource-name: virtual-network-peering-from-target
    crossplane.io/external-name: from-shoot--test--test-dev-us
  labels:
    name: virtual-network-peering-from-target
spec:
  deletionPolicy: Delete
  forProvider:
    remoteVirtualNetworkIdSelector:
      matchControllerRef: true
      policy:
        resolution: Required
        resolve: Always
    resourceGroupName: shoot--test--test-dev-us
    virtualNetworkName: shoot--test--test-dev-us
---

Fixes #480

[porridge]

This looks awesome! Would you mind adding some tests?

[jtucci]

This looks awesome! Would you mind adding some tests?

@porridge Sure thing! I just updated the test cases to allow for several 'actual' resources to be created and added a case to test the label matching.

[porridge]

The error returning fix LGTM overall, but I have one worry, see inline.
Also, please take a look at the TestCheckResourceIntegration/match_object_by_labels,_field_mismatch that started failing.

[porridge]

[...] please take a look at the TestCheckResourceIntegration/match_object_by_labels,_field_mismatch that started failing.

Any ideas about this one, @jtucci ?

[jtucci]

[...] please take a look at the TestCheckResourceIntegration/match_object_by_labels,_field_mismatch that started failing.

Any ideas about this one, @jtucci ?

I just pushed the fix, the integration tests are passing locally for me now.

[porridge]

❤️