[valkey-resources] Add a local E2E Makefile for valkey-resources (kind + operator + ValkeyCluster Ready)

[Bloodraven21]

Summary

Add a Makefile that maintainers can run locally to verify a valkey-resources change against a real operator before approving a PR.

Today, CI only runs helm lint and helm unittest (.github/workflows/unittest-resources.yml). That proves the chart renders, but it does not prove that the rendered ValkeyCluster:

• Is accepted by the Kubernetes API server.
• Is reconciled successfully by the operator.
• Results in a healthy cluster.

Reviewing changes to cluster.spec currently requires manually inspecting rendered YAML.

The scope of this proposal is only the local Makefile. Integrating it into CI is a separate follow-up.

---

Why valkey-resources Needs Its Own E2E

• The ValkeyCluster CRD must exist before valkey-resources installs, and Helm does not upgrade CRDs. Installation ordering is documented in the README but is never actually exercised.
• cluster.spec is effectively a passthrough (templates/valkeycluster.yaml), while values.schema.json validates only shards and replicas. Every other field is unchecked until kubectl apply.
• The chart pins appVersion: v0.4.0, but nothing verifies that the examples and values still work correctly with that operator version.

---

Design

Each phase becomes an individual Make target so reviewers can stop, inspect the cluster, fix something, and rerun only the failed step.

make -C valkey-resources/e2e kind-up operator-install
# stop here and inspect

make -C valkey-resources/e2e wait-ready
# rerun only readiness

make -C valkey-resources/e2e diagnostics
# dump cluster state at any time

---

Proposal

Create:

valkey-resources/e2e/Makefile

with make e2e as the default full workflow.

Configurable Variables

Variable	Default
VALUES	../examples/minimal.yaml
KIND_CLUSTER	valkey-resources-e2e
NODE_IMAGE	(empty, Kind default)
OPERATOR_NS	valkey-operator-system
CLUSTER_NS	valkey
RELEASE	my-cluster
TIMEOUT	5m

---

Targets

Target	Purpose
e2e	Full workflow: lint → template → kind-up → operator-install → crd-check → install → wait-ready → verify-topology → smoke → uninstall-check → kind-down
preflight	Verify kind, kubectl, helm, and docker are available
lint	Run helm lint ./valkey-resources
template	Run helm template with $(VALUES) so rendering failures occur before Kind is started
kind-up	Create the Kind cluster if it doesn't exist and warn if Kubernetes is older than 1.31 (the documented minimum)
kind-down	Delete the Kind cluster
operator-install	Install the local ./valkey-operator chart and wait for the deployment to become ready
crd-check	Verify valkeyclusters.valkey.io and valkeynodes.valkey.io exist. Fail with a clear error otherwise
install	Install the local ./valkey-resources chart using $(VALUES)
wait-ready	Wait for the ValkeyCluster to reach status.state=Ready
verify-topology	Verify spec.shards, spec.replicas, expected ValkeyNode count (shards × (1 + replicas)), status.readyShards, and that every pod is Ready
smoke	Run valkey-cli CLUSTER INFO and verify cluster_state:ok, followed by a SET/GET round-trip
uninstall-check	Uninstall the release and verify ValkeyNodes and pods are garbage collected
diagnostics	Collect describe, ValkeyNodes, events, operator logs, and pod logs
clean	Run kind-down and remove temporary files

---

Failure Handling

e2e should automatically run diagnostics whenever a phase fails while still exiting with a non-zero status.

A simple implementation is:

target:
	@some-command || { \
		$(MAKE) diagnostics; \
		exit 1; \
	}

Since make does not support shell traps directly, each failure-prone phase should invoke diagnostics explicitly.

---

Cluster Lifecycle

kind-down is intentionally a separate target instead of always running automatically.

• On success, make e2e tears the cluster down.
• On failure, the Kind cluster remains available for investigation.

---

Documentation

Add:

valkey-resources/e2e/README.md

covering:

• Prerequisites
• Configuration variables
• Common workflows
• Individual targets
• Troubleshooting

---

Acceptance Criteria

• make -C valkey-resources/e2e e2e succeeds on a clean machine using examples/minimal.yaml.
• Every target can be run independently and rerun without rebuilding previous steps.
• The workflow fails with clear, actionable errors when:
  • CRDs are missing
  • The cluster never reaches Ready
  • The resulting topology is incorrect
• Failed runs leave the Kind cluster intact for debugging.
• make diagnostics provides sufficient information to understand the failure.