Issue

Resolves #178
Resolves #136

Description

This PR adds support for passing in custom resource documents to the validator rules check command via the --custom-resources flag. The --custom-resources flag can receive either a path to a directory or to a file.

File selection

If a directory path is provided, we check each file within the directory for CR documents. Note that we walk the entire file tree from a particular directory. This means that users are able to organize their CRs in a manner like this:

❯ tree tests/integration/_validator/testcases/data/validator-crs
tests/integration/_validator/testcases/data/validator-crs
├── combined.yaml
├── network
│   └── network.yaml
└── oci
    └── oci.yaml

3 directories, 3 files

In the above example, we'll look for CRs within the slice of all 3 files found (combined.yaml, network.yaml, and oci.yaml). Users have the flexibility to organize their CRs as they desire.

If a single file is instead passed in via the --cr flag, we only work with a slice containing the single file that was provided.

CR Unmarshalling

Given a slice of files (which may only contain a single file), we range over each file and attempt the following:

We try to read all the CR documents that are contained in that file and run validations against them.

For instance, if the path to the following file is passed in:

apiVersion: validation.spectrocloud.labs/v1alpha1
kind: OciValidator
metadata:
  name: oci-validator-combined-oci-rules
spec:
  ociRegistryRules:
    - name: "public oci registry with tag"
      host: "docker.io"
      validationType: "none"
      artifacts:
        - ref: "library/redis:7.2.4"
---
apiVersion: validation.spectrocloud.labs/v1alpha1
kind: NetworkValidator
metadata:
  name: network-validator-combined-network-rules
spec:
  dnsRules:
  - name: Resolve Google
    host: google.com

We'll run validations against both he network and the oci plugin rules that are defined in the file. Users can choose to store all CRs in a single file, or spread them across multiple files. Whatever configuration they choose will work.

Error handling

Succesfull validation can result in a lot of text being printed to a users terminal. Given this, I wanted to avoid "hiding" an error in the flood of validation results. If any CR document is invalid, an error message will be returned and no validations will run. It'll be obvious what failed and how to fix it.