mirror of
https://github.com/vmware-tanzu/velero.git
synced 2026-11-08 12:26:36 +00:00
KrishhnaT
3a408a24be
* e2e: add a target that runs the tests on a kind cluster it creates Running the e2e tests locally means assembling a cluster, an object store with two buckets, a credentials file, an address the cluster can reach MinIO on, and a Velero image built and loaded, before any GINKGO_LABELS is useful. That is a lot of setup to get wrong, and nothing in the repo does it. Add hack/run-e2e-kind.sh and a run-e2e-kind target that wraps it. It creates the cluster, starts MinIO, builds and loads the image, runs the suite, and removes what it created on the way out, including when the tests fail or the run is interrupted. FAIL_FAST=true keeps the test bed and prints how to remove it, as it does for the suite itself. The cluster's kubeconfig is written to a temporary directory rather than merged into the caller's, so ~/.kube/config is untouched and the current context does not change. The MinIO container is named after the cluster, and the script refuses to start if that name is already taken rather than removing a container it did not create. FEATURES=EnableCSI delegates to hack/install-csi-hostpath.sh. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * Add changelog for #10652 Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * e2e: point the kind target's CSI runs at a CSI-backed StorageClass The target installs csi-driver-host-path when EnableCSI is asked for, but left the suite's own StorageClass alone. InstallStorageClasses falls back to testdata/storage-class/<provider>.yaml when --storage-class-file is not given, and the kind one provisions with rancher.io/local-path, so the run installed a snapshot-capable driver and then created e2e-storage-class on a provisioner that cannot snapshot. The example in the script's own header could not have worked. Pass kind-csi.yaml for a CSI run, which is the file the CSI job in CI already uses. Non-CSI runs pass an empty value, which is what the Makefile defaults to, so they are unchanged. While here, match FEATURES as the comma-separated list the flag accepts rather than comparing the whole value, so EnableCSI,EnableAPIGroupVersions still installs the driver. Same reasoning as the Go side in #10661. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * e2e: fix five faults in the kind runner found in review Teardown deleted the cluster whether or not this run created it. The EXIT trap is installed before the cluster exists, so an early exit, including the check that refuses an existing MinIO container, removed a cluster named velero-e2e that belonged to someone else. The script already refused to remove a MinIO container it did not create, after an earlier version deleted one that was in use; the cluster needed the same rule and did not have it. It now refuses a cluster name that is taken and tracks whether it created one. MinIO was started with "server /data", which replaces the entrypoint. CI passes no command and relies on the image starting the server itself, and the bitnami image this script tells the user to build runs as UID 1001 and cannot create a data directory at the filesystem root, so the recommended image could not come up. The command is now empty by default, with MINIO_ARGS for an image that needs one, such as upstream minio/minio, and the readiness failure says so. The image name was taken with ${VELERO_IMAGE%%:*}, which strips from the first colon, so localhost:5000/velero:e2e-local became "localhost" and the load asked for a tag that was never built. Strip only the final tag. The loaded tag was hardcoded to -linux-amd64, but the container target appends the platform from go env when BUILD_OUTPUT_TYPE is docker, so an arm64 workstation built -linux-arm64 and the load failed before any test ran. Resolve the platform once and use it for both the load and the suite. Finally, the resolved tag was handed to the inner make through the environment. A command-line assignment to the outer make propagates through MAKEFLAGS and outranks the environment, so "make -C test run-e2e-kind VELERO_IMAGE=velero:custom" ran the suite against velero:custom while the script had loaded velero:custom-linux-amd64. Pass it as an argument instead. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> * e2e: take only the architecture from go env, the image OS is always linux The container target fixes ALL_OS to linux when BUILD_OUTPUT_TYPE is docker and takes only the architecture from go env, so the tag it produces ends in -linux-<arch> on every host. Deriving the OS from go env GOOS instead meant a Darwin workstation computed -darwin-<arch> and tried to load a tag that was never built, which matters because a Darwin host still needs a Linux image to load into kind. Suggested in review. Signed-off-by: krishhna24 <krishhnatupedev@gmail.com> --------- Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>