You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to test the virtualmachine-controller's behavior, we brutally download the KubeVirt API repository and generate the CRD manifests in the generate-kubevirt-crd target and make it a dependency of the test target:
.PHONY: generate-kubevirt-crd
generate-kubevirt-crd: controller-gen ## Clone KubeVirt API and generate CustomResourceDefinition objects for integration testing purposes.
TMP_DIR=$$(mktemp -d -p /tmp/);\
KUBEVIRT_API_DIR=$$TMP_DIR/kubevirt-api;\
git clone --depth 1 --branch $(KUBEVIRT_API_VERSION) https://github.com/kubevirt/api $$KUBEVIRT_API_DIR;\$(CONTROLLER_GEN) crd:allowDangerousTypes=true paths="$$KUBEVIRT_API_DIR/core/v1/..." output:crd:artifacts:config=config/kubevirt-crd;\
rm -rvf $$TMP_DIR;\
rm -vf config/kubevirt-crd/kubevirt.io_datavolumetemplatespecs.yaml
...
.PHONY: test
test: manifests generate generate-kubevirt-crd fmt vet envtest ## Run tests.
KUBEBUILDER_ASSETS="$(shell $(ENVTEST) use $(ENVTEST_K8S_VERSION) --bin-dir $(LOCALBIN) -p path)" go test ./... -coverprofile cover.out
That's because we need those KubeVirt CRD manifests to be loaded when setting up the test environment for testing the virtualmachine controller:
testEnv=&envtest.Environment{
CRDDirectoryPaths: []string{
filepath.Join("..", "..", "..", "config", "crd", "bases"),
// TODO: This requires collaboration from Makefile to pull down the// api repo and generate CRD objects beforehand. It should be// possible to leverage the CRD option to import CRD objects// directly instead of adding them from directories.filepath.Join("..", "..", "..", "config", "kubevirt-crd"),
},
ErrorIfCRDPathMissing: true,
BinaryAssetsDirectory: filepath.Join("..", "..", "..", "bin", "k8s",
fmt.Sprintf("1.28.0-%s-%s", runtime.GOOS, runtime.GOARCH)),
}
This could be done in a more elegant way. Currently, I'm not sure how, but there's a CRD field in envtest.Environment (godoc) that we can leverage (perhaps):
// CRDs is a list of CRDs to install.// If both this field and CRDs field in CRDInstallOptions are specified, the// values are merged.CRDs []*apiextensionsv1.CustomResourceDefinition
The text was updated successfully, but these errors were encountered:
In order to test the virtualmachine-controller's behavior, we brutally download the KubeVirt API repository and generate the CRD manifests in the
generate-kubevirt-crd
target and make it a dependency of thetest
target:That's because we need those KubeVirt CRD manifests to be loaded when setting up the test environment for testing the virtualmachine controller:
This could be done in a more elegant way. Currently, I'm not sure how, but there's a
CRD
field inenvtest.Environment
(godoc) that we can leverage (perhaps):The text was updated successfully, but these errors were encountered: