Skip to content

test(e2e): add nested-cluster e2e suite for sds-object#19

Merged
duckhawk merged 3 commits into
mainfrom
feat/e2e-tests
Jun 29, 2026
Merged

test(e2e): add nested-cluster e2e suite for sds-object#19
duckhawk merged 3 commits into
mainfrom
feat/e2e-tests

Conversation

@duckhawk

@duckhawk duckhawk commented Jun 29, 2026

Copy link
Copy Markdown
Member

What

Adds an end-to-end test suite under e2e/, modeled on the sds-elastic and state-snapshotter suites. A storage-e2e nested cluster exercises the documented ObjectStorageCluster / ObjectBucket lifecycle on a single shared cluster via Ginkgo Ordered specs (create → validation → delete, randomization off).

Coverage

  • create: ObjectStorageCluster → Ready (asserts status.phase / backend.type / endpoint.internal); ObjectBucket → Ready (status.bucketName / secretRef).
  • credentials Secret: all five standardised S3_* / AWS_* keys present + non-empty, and owned by the ObjectBucket.
  • S3 round-trip: a real mc write/list/read Job against the bucket endpoint using the generated credentials.
  • validation: validating webhooks (deny 2nd System cluster, deny duplicate bucket name per cluster) + CRD CEL rules (immutable spec.type, Heavy↔elasticClusterRef, storage.class required for Lightweight/Full).
  • delete: finalizer-driven removal of the bucket (+ owned credentials Secret GC) and the cluster.

Profiles

Selectable via E2E_OSC_TYPE (default System — Garage on control-plane / hostPath, needs no StorageClass, no extra modules, cheapest reliable path). Lightweight / Full / Heavy are supported and gated on their required env knobs (E2E_STORAGE_CLASS, E2E_ELASTIC_CLUSTER_REF); enable the corresponding modules in tests/cluster_config.yml first (commented inline).

Notes

  • storage-e2e consumed as a pinned pseudo-version; sds-object/api via replace => ../api.
  • No CI workflow added — consistent with sds-elastic / state-snapshotter, where e2e runs are manual. See e2e/README.md for run instructions and env knobs.
  • Compile-verified: go build ./..., go vet ./..., go test -c ./tests/, gofmt all clean. Not executed against a live cluster in this PR.

duckhawk and others added 3 commits June 29, 2026 15:04
Adds an end-to-end suite under e2e/, modeled on the sds-elastic and
state-snapshotter suites: a storage-e2e nested cluster runs the documented
ObjectStorageCluster / ObjectBucket lifecycle on a single shared cluster via
Ginkgo Ordered specs.

Coverage:
- cluster create -> Ready (status phase/backend/endpoint)
- bucket create -> Ready, standardised S3 credentials Secret (keys + ownership)
- real S3 write/list/read round-trip through the generated credentials (mc Job)
- admission guards: validating webhooks (single System cluster, unique bucket
  name) + CRD CEL rules (immutable type, Heavy<->elasticClusterRef, storage.class)
- finalizer-driven deletion of bucket (+owned Secret) and cluster

The profile is selectable via E2E_OSC_TYPE (default System: no StorageClass,
no extra modules, cheapest reliable CI path); Lightweight/Full/Heavy gated on
their required env knobs. storage-e2e is consumed as a pinned pseudo-version;
sds-object/api via replace => ../api.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…n label

Add a thin caller workflow that invokes the reusable
deckhouse/storage-e2e/.github/workflows/e2e.yml pipeline, gated by the e2e/run
PR label. Configured for this module: module_path=e2e, test_package=./tests/,
cluster_config=e2e/tests/cluster_config.yml, cluster_provider=commander (each
run creates a fresh cluster via the Commander API and tears it down). Documents
the label trigger and Commander secrets in e2e/README.md.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…les)

Point the e2e caller at the new storage-e2e pipeline capabilities so the suite
actually runs against a Commander-created cluster:
- add tests/cluster_config.ci.yml whose sds-object modulePullOverride is
  "${E2E_MODULE_IMAGE_TAG}" (resolved by the enable-modules step). It is a
  separate file because the local-run config loader rejects ${...}; the literal
  cluster_config.yml is kept for local runs.
- workflow: cluster_config -> the CI file, and module_image_tag: pr<N> so the
  pipeline installs the image built for this PR.
- README: document the bootstrap -> enable-modules -> run-tests flow and the
  prerequisite that the PR dev image (pr<N>) is built before e2e.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@duckhawk duckhawk merged commit 4aad120 into main Jun 29, 2026
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant