test(e2e): add Helm-chart upgrade scenario#1610
test(e2e): add Helm-chart upgrade scenario#1610Sanil2108 wants to merge 2 commits intokedacore:mainfrom
Conversation
Adds a dedicated e2e check that exercises the Helm-chart upgrade path
of the http-add-on:
1. Install a previous release via `helm upgrade --install
kedacore/http-add-on --version $HTTPADDON_UPGRADE_FROM_VERSION`.
2. Create a sample workload + HTTPScaledObject and verify it scales
from 0 to maxReplicaCount under load.
3. Upgrade to the target release
(`$HTTPADDON_UPGRADE_TO_VERSION`).
4. Verify the pre-existing HTTPScaledObject is still reconciled by
the upgraded operator and that the deployment continues to scale
correctly on load.
Skipped by default; only runs when both
HTTPADDON_UPGRADE_FROM_VERSION and HTTPADDON_UPGRADE_TO_VERSION env
vars are set. The intent is a dedicated CI job, since the scenario
swaps the cluster-wide add-on release that the rest of the e2e suite
assumes is pinned.
Refs kedacore#1427
Signed-off-by: Sanil2108 <[email protected]>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
There was a problem hiding this comment.
Pull request overview
Adds a new skip-by-default e2e check that exercises a Helm chart upgrade path for the KEDA HTTP Add-on and validates that an existing HTTPScaledObject continues to reconcile and scale across the upgrade.
Changes:
- Add
upgrade_httpsoe2e test that installs an older chart version, validates scale-out, upgrades to a target chart version, and validates scaling behavior post-upgrade. - Gate the scenario behind
HTTPADDON_UPGRADE_FROM_VERSION/HTTPADDON_UPGRADE_TO_VERSIONenvironment variables.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| func installOrUpgradeAddon(t *testing.T, version string) { | ||
| t.Helper() | ||
| _, err := ExecuteCommand("helm repo add kedacore https://kedacore.github.io/charts") | ||
| require.NoErrorf(t, err, "cannot add kedacore helm repo - %s", err) | ||
| _, err = ExecuteCommand("helm repo update kedacore") | ||
| require.NoErrorf(t, err, "cannot update kedacore helm repo - %s", err) | ||
| _, err = ExecuteCommand(fmt.Sprintf( | ||
| "helm upgrade --install %s %s --version %s --namespace %s --wait", | ||
| releaseName, chartRef, version, KEDANamespace, | ||
| )) | ||
| require.NoErrorf(t, err, "cannot install/upgrade %s to version %s - %s", releaseName, version, err) | ||
| } |
| t.Log("--- HTTPScaledObject survives upgrade ---") | ||
| // Give the new operator a moment to reconcile pre-existing HTTPScaledObject resources. | ||
| assert.True(t, WaitForDeploymentReplicaReadyCount(t, kc, deploymentName, testNamespace, maxReplicaCount, 6, 10), | ||
| "expected HTTPScaledObject to still route traffic and keep the deployment at max replicas post-upgrade") |
…d after upgrade Two review concerns from Copilot: 1. Installing the Helm release into the `keda` namespace conflicts with the `keda-add-ons-http-*` resources `tests/utils/setup_test.go` already created via `make deploy-e2e`. `make undeploy` them before the first Helm install so the release can take ownership cleanly. Added a matching `helm uninstall` in t.Cleanup so the cluster is left without the Helm release at the end (a subsequent `make deploy-e2e` can restore the kustomize install). 2. The post-upgrade `WaitForDeploymentReplicaReadyCount(maxReplicaCount)` assumed load from the pre-upgrade scale-out was still pending, but `scaledownPeriod: 10s` expires before the upgrade completes. Added an explicit scale-in between the baseline and upgrade blocks, then a fresh scale-out after the upgrade — which is the real assertion we want (HTTPScaledObject survives the upgrade and still routes traffic under new load). Refs kedacore#1427 Signed-off-by: Sanil2108 <[email protected]>
|
Thanks for the review! Addressed both points in the follow-up commit:
|
Summary
Refs #1427. Adds an upgrade scenario to `tests/checks/` that installs a previous release of the `kedacore/http-add-on` Helm chart, verifies a basic HTTPScaledObject scales on load, runs `helm upgrade` to a target version, and then verifies the same HTTPScaledObject still reconciles and scales after the upgrade.
How it runs
The test is skipped unless both env vars are set:
So the addition is a no-op for the existing e2e suite. Running it requires a dedicated CI job (or a local invocation) that sets both variables before running `go run -tags e2e ./tests/run-all.go` with an `E2E_TEST_REGEX` narrowed to `upgrade`.
Why skip-by-default
The main legacy e2e suite installs the add-on once at the start (`TestDeployKEDAHttpAddOn`) and assumes every check runs against that single, pinned release. The upgrade scenario intentionally swaps the cluster-wide release, so it can't safely share a run with other checks (runner uses `concurrentTests=2`). Guarding on the env vars keeps the existing suite's assumptions intact.
What the test verifies
Notes / open questions for the maintainer
Refs #1427