Files
velero/test/testdata/storage-class
KrishhnaTandGitHub 931a805207
Run the E2E test on kind / setup-test-matrix (push) Failing after 3s
e2e-test-kind.yaml / extract (push) Failing after 6s
Run the E2E test on kind / get-go-version (push) Failing after 7s
Run the E2E test on kind / build (push) Skipped
Run the E2E test on kind / run-e2e-test (push) Skipped
Scorecard supply-chain security / Scorecard analysis (push) Skipped
Run the E2E test on kind / run-csi-e2e-test (push) Skipped
push.yml / extract (push) Failing after 6s
Main CI / get-go-version (push) Failing after 7s
Main CI / Build (push) Skipped
e2e: run the CSI cases on kind in CI (#10644)
* e2e: run the CSI cases on kind in CI

The CSI cases have never run in CI. kind has no driver that can take
snapshots, so they were skipped by omission: no label set selects them
and FEATURES is never set.

Add a job that installs the snapshot stack with
hack/install-csi-hostpath.sh and runs them against it, with the
StorageClass pointed at a hostpath definition so the volumes can actually
be snapshotted.

It is a separate job rather than a fifth entry in the existing matrix.
Installing the stack measures at about 3.4 minutes, which every job would
pay, and ResourceFiltering already peaks six minutes under its timeout.
This also keeps a CSI problem from reddening a job that has nothing to do
with CSI.

It runs on the newest three Kubernetes versions. csi-driver-host-path
ships deploy manifests only for recent releases, so the older end of the
matrix has nothing to install.

Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>

* Add changelog for #10644

Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>

---------

Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
2026-10-13 20:05:58 -04:00
..

The test/testdata/storage-class directory contains the StorageClass YAMLs used for E2E. The public cloud provider (including AWS, Azure and GCP) has two StorageClasses.

  • The provider-name.yaml contains the default StorageClass for the provider. It uses the CSI provisioner.
  • The provider-name-legacy.yaml contains the legacy StorageClass for the provider. It uses the in-tree volume plugin as the provisioner. By far, there is no E2E case using them.

The vSphere environment also has two StorageClass files.

  • The vsphere-legacy.yaml is used for the TKGm environment.
  • The vsphere.yaml is used for the VKS environment.

The ZFS StorageClasses only have the default one. There is no in-tree volume plugin used StorageClass used in E2E.

The kind StorageClass uses the local-path provisioner. Will consider adding the CSI provisioner when there is a need.

The StorageClass definitions are configurable. --storage-class-file and --storage-class-file-2 take a manifest for each class, so a cluster whose volumes need a different provisioner or parameters can be targeted without editing the files here, for example pointing at a CSI driver on kind. The class names stay e2e-storage-class and e2e-storage-class-2, since the test cases refer to them; only the definition changes. Unset, the provider's own file above is used for both.

Setting --storage-class-file-2 to the empty string runs without a second StorageClass. The cases that map between two of them skip, and everything else runs.