update vendor for new test changes and vendoring

Author: deads2k

README.md

@@ -52,6 +52,42 @@ FeatureGateMyFeatureName = newFeatureGate("MyFeatureName").
 			mustRegister()
 ```
 
+### defining tests
+Tests are logically associated with FeatureGates.
+When adding any FeatureGated functionality a new test file is required.
+The test files are located in `<group>/<version>/tests/<crd-name>/FeatureGate.yaml`:
+```
+route/
+  v1/
+    tests/
+      routes.route.openshift.io/
+        AAA_ungated.yaml
+        ExternalRouteCertificate.yaml
+```
+Here's an `AAA_ungated.yaml` example:
+```yaml
+apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this.
+name: Route
+crdName: routes.route.openshift.io
+tests:
+```
+
+Here's an `ExternalRouteCertificate.yaml` example:
+```yaml
+apiVersion: apiextensions.k8s.io/v1 # Hack because controller-gen complains if we don't have this.
+name: Route
+crdName: routes.route.openshift.io
+featureGate: ExternalRouteCertificate
+tests:
+```
+
+The integration tests use the crdName and featureGate to determine which tests apply to which manifests and automatically
+react to changes when the FeatureGates are enabled/disabled on various FeatureSets and ClusterProfiles.
+
+[`gen-minimal-test.sh`](tests/hack/gen-minimal-test.sh) can still function to stub out files if you don't want to
+copy/paste an existing one.
+
+
 ## defining new APIs
 
 When defining a new API, please follow [the OpenShift API
@@ -172,6 +208,18 @@ No, signing a team up to be a no-FF team includes some basic education on the pr
 participants are aware the team is moving to that model.  If you'd like to sign your team up, please speak with Gina Hargan who will
 be happy to help on-board your team.
 
+## vendoring generated manifests into other repositories
+If your repository relies on vendoring and copying CRD manifests (good job!), you'll need have an import line that
+depends on the package that contains the CRD manifests.
+For example, adding
+```go
+import (
+	_ "github.com/openshift/api/operatoringress/v1/zz_generated.crd-manifests"
+)
+```
+to any .go file will work, but some commonly chosen files are `tools/tools.go` or `pkg/dependencymagnet/doc.go`.
+Once added, a `go mod vendor` will pick up the package containing the manifests for you to copy.
+
 ## generating CRD schemas
 
 Since Kubernetes 1.16, every CRD created in `apiextensions.k8s.io/v1` is required to have a [structural OpenAPIV3 schema](https://kubernetes.io/blog/2019/06/20/crd-structural-schema/). The schemas provide server-side validation for fields, as well as providing the descriptions for `oc explain`. Moreover, schemas ensure structural consistency of data in etcd. Without it anything can be stored in a resource which can have security implications. As we host many of our CRDs in this repo along with their corresponding Go types we also require them to have schemas. However, the following instructions apply for CRDs that are not hosted here as well.