GnuMake is used to drive a set of scripts that handle linting, testing, compiling, and containerizing. Executing the scripts directly is not supported at present.
NOTE: Standard builds require a running Docker daemon!
The standard workflow is performed inside a helper container to normalize the build and test environment for all devs.
$ make all
executes the full workflow. For granular control of the workflow, several Make targets are defined:
all
: cleans up previous build artifacts, restarts the builder container, compiles the plugin, builds image and pushes it to the local clusterbuild-all
: compiles the plugin if source files changedbuild-image
: compiles the plugin if necessary and builds the imagebuild-dirs
: creates output directoriespush
: pushes image to local registrycluster-push-image
: pushes image to registry of the local clusterlocal-deploy-velero
: deploys Minio and Velero to the local clusterlocal-undeploy-velero
: removes Minio and Velero fro the local clusteradd-plugin
: adds the plugin to Velero deployment on the local clusterremove-plugin
: removes the plugin from Velero deployment on the local clustergomod-update
: updates module dependeciesbuild-builder
: builds builder imagepush-builder
: pushes builder image to local registryclean
: stops the builder container and removes output directoriestest
: execute teststest-functional
: build and run functional testsrebuild-functest
: clean and build functional testsclean-test
: clean functional testsstop-builder
: stops builder containercluster-up
: start local k8s cluster and deploy KubeVirt and CDI on itcluster-down
: stop local k8s clustercluster-sync
: undeploy the plugin, rebuild it and redeploy it
Several variables are provided to alter the targets of the above Makefile
recipes.
These may be passed to a target as $ make VARIABLE=value target
IMAGE
: (default: registry:5000/kubevirt-velero-plugin) Plugin image nameVERSION
: (default: 0.1) Plugin image versionWHAT
: The path from the repository root to a target directory (e.g.make test WHAT=pkg/importer
)
(This section is a work in progress.)
If using a standard bare-metal/local laptop rhel/kvm environment where nested virtualization is supported then the standard kubevirtci framework can be used.
Environment Variables and Supported Values
Env Variable | Default | Additional Values |
---|---|---|
KUBEVIRT_PROVIDER | k8s-1.19 | k8s-1.18, k8s-1.20, external |
KUBEVIRT_STORAGE* | none | rook-ceph-default, hpp, nfs, ember_lvm |
KUBEVIRT_PROVIDER_EXTRA_ARGS | ||
NUM_NODES | 1 | 2-5 |
To Run Standard Functional Tests
# make cluster-up
# make cluster-sync
# make test-functional
To run specific functional tests, you can leverage ginkgo command line options as follows:
# make TEST_ARGS="--test-args=-ginkgo.focus=<test_suite_name>" test-functional
E.g. to run the tests in transport_test.go:
# make TEST_ARGS="--test-args=-ginkgo.focus=Transport" test-functional
Clean Up
# make cluster-down
All PRs should originate from forks of kubevirt.io/containerized-data-importer. Work should not be done directly in the upstream repository. Open new working branches from master/HEAD of your forked repository and push them to your remote repo. Then submit PRs of the working branch against the upstream master branch.
This project uses go modules
as it's dependency manager. At present, all project dependencies are vendored; using go mod
is unnecessary in the normal work flow.
go modules
automatically scans and vendors in dependencies during the build process, you can also manually trigger go modules by running 'make dep-update'.
Velero is deployed with minio with dummy credentials. See [hack/velero/credentials-velero].