When we attempted to release the UDS state feature, our release pipeline caught a bug where state was being created in a cluster that existed before deploying the slim-dev bundle.
This bug should have been caught sooner by the nightly pipelines but was not. Noting that the bug was caught because our release pipeline starts up a cluster using the k3d action which deploys an empty k3d cluster.
Describe what should be investigated or refactored
In our release-pipeline, we use the our k3d Github action to download the k3d binary and start a k3d cluster (ref). Because of this, 2 clusters get created in the Github runner
In our nightly-uds-core smoke test, we install k3d but do not start a k3d cluster; in this case, only 1 cluster is created
There are 2 scenarios that should be tested in both pipelines:
Cluster already exists when we deploy slim-dev
Cluster does not already exist when we deploy slim-dev
Update the smoke tests to cover the above scenarios in both nightly and release pipelines (can potentially create a resuable workflow to avoid duplicates configs)
Context
When we attempted to release the UDS state feature, our release pipeline caught a bug where state was being created in a cluster that existed before deploying the slim-dev bundle.
This bug should have been caught sooner by the nightly pipelines but was not. Noting that the bug was caught because our release pipeline starts up a cluster using the k3d action which deploys an empty k3d cluster.
Describe what should be investigated or refactored
Smoke tests in our release pipeline vs nightly-uds-core are slightly different.
There are 2 scenarios that should be tested in both pipelines:
Update the smoke tests to cover the above scenarios in both nightly and release pipelines (can potentially create a resuable workflow to avoid duplicates configs)