Add test helm upgrade path #1156
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1156 +/- ##
==========================================
- Coverage 83.63% 83.62% -0.02%
==========================================
Files 81 81
Lines 6943 6943
==========================================
- Hits 5807 5806 -1
- Misses 913 914 +1
Partials 223 223
Flags with carried forward coverage won't be shown. Click here to find out more.
|
eguzki
force-pushed
the
1123-add-test-helm-upgrade-path
branch
3 times, most recently
from
7ea9e5b to
5016817
Compare
Signed-off-by: Eguzki Astiz Lezaun <[email protected]>
eguzki
force-pushed
the
1123-add-test-helm-upgrade-path
branch
from
5016817 to
c048210
Compare
Signed-off-by: Eguzki Astiz Lezaun <[email protected]>
eguzki
force-pushed
the
1123-add-test-helm-upgrade-path
branch
from
9339ed9 to
1784199
Compare
eguzki
added
kind/enhancement
| description: Cluster server URL | ||
| required: false | ||
| type: string | ||
| clusterToken: |
There was a problem hiding this comment.
I'm not sure how secure is to pass down sensitive info like tokens from inputs, might want to check the docs or at least the full output logs with debug mode enabled.
There was a problem hiding this comment.
there is one specific step to have the token redacted Mask cluster token. Good enough?
| description: Kuadrant start version | ||
| required: true | ||
| type: string | ||
| clusterServer: |
There was a problem hiding this comment.
Is having an external k8s cluster desired by these kind of tests? If not, we can just rely on kind
There was a problem hiding this comment.
yes, quoting from #1112
Ideally we would install the previous version into a cluster such as a kind cluster (although it would be ideal to be able to target a cluster also )
.github/workflows/test-upgrade.yaml
Outdated
| helm-charts-upgrade-test: | ||
| runs-on: ubuntu-latest | ||
| name: Helm Charts Upgrade Test | ||
| if: ${{ github.event_name == 'workflow_dispatch' }} |
There was a problem hiding this comment.
not needed since the only event listener is workflow_dispatch https://github.com/Kuadrant/kuadrant-operator/pull/1156/files#diff-e3c60a7e344a4151f98dbfd60770be22bc6169d9c3c2cb7c4748529a3e9a6333R4-R5
| make helm-dependency-build | ||
| - name: Start upgrade to kuadrant ${{ steps.upgrade-version.outputs.version }} | ||
| run: | | ||
| bin/helm upgrade kuadrant charts/kuadrant-operator \ |
There was a problem hiding this comment.
we are not gonna be upgrading to pre-releases charts, are we?
There was a problem hiding this comment.
because if we are, we might need to pass the --devel flag
There was a problem hiding this comment.
Upgrade to pre-release charts can be tested.
The target (version being upgraded to) chart is determined by the git reference where you run the tests. Thus, the chart is available locally in the filesystem, hence the path charts/kuadrant-operator.
make/helm.mk
Outdated
|
|
||
| .PHONY: helm-print-chart-version | ||
| helm-print-chart-version: $(HELM) ## Reads chart version | ||
| @$(HELM) show chart charts/$(REPO) | grep -E "^version:" | awk '{print $$2}' |
There was a problem hiding this comment.
given this will show the local info in charts/Chart.yaml, this workflow is only meant to be run from a branch (i.e. release branch) that has the new helm chart package for the release, right?
make/helm.mk
Outdated
|
|
||
| .PHONY: helm-print-chart-version | ||
| helm-print-chart-version: $(HELM) ## Reads chart version | ||
| @$(HELM) show chart charts/$(REPO) | grep -E "^version:" | awk '{print $$2}' |
There was a problem hiding this comment.
We should stop using the $REPO var within the charts:
| @$(HELM) show chart charts/$(REPO) | grep -E "^version:" | awk '{print $$2}' | |
| @$(HELM) show chart charts/$(CHART_NAME) | grep -E "^version:" | awk '{print $$2}' |
|
It's looking good, I'd like to know if it's meant to run in an external k8s cluster, and if so, we might want to see if the secrets are treated correctly. Also, in that case, a cleaning step might be needed. |
Signed-off-by: Eguzki Astiz Lezaun <[email protected]>
Signed-off-by: Eguzki Astiz Lezaun <[email protected]>
|
Thanks for the review @didierofrivia Addressed some comments and answered questions. |
What
Implements #1123 and is part of the work being done for #1112
It's a Github Action Workflow to test the Kuadrant upgrade process using helm charts.
It is being triggered manually (
on.workflow_dispatch) and accepts as input:kuadrantStartVersion: Kuadrant start version (required). For example:1.0.0(withoutvprefix)kuadrantNamespace: Namespace where Kuadrant is installed (optional defaults tokuadrant-system).clusterServer: Cluster server URL (optional defaults to local kind cluster). For example:https://example.com:443clusterToken: Cluster Server Bearer Token (optional defaults to local kind cluster token). For example:sha256~abcdefghijk12345432432The workflow installs published Kuadrant release from
https://kuadrant.io/helm-chartswith the version specified bykuadrantStartVersion. As of today, existing release versions:Then, deploys kuadrant CR and checks status is Ready. The kuadrant operator, runs a set of tests to mark the resource status as ready, so effectively, the workflow is relying on those tests to verify installation.
When the starting point installation is ready, it proceeds with the upgrade process. The upgrade is being carried out running helm upgrade command. The command waits until all deployments are ready (with a timeout set to 3 mins) and fails if some deployment is not ready after the timeout expires. Upgrade may fail for instance if some referenced docker image is not valid or does not exist. The upgrade verification steps by the workflow relies, once again, on the kuadrant CR status. After the upgrade, the kuadrant CR status should be Ready to pass the test. For example, if for whatever reason, let's say the limitador operator, or limitador instance, is not up and running, kuadrant CR would report on the status and the upgrade test would fail.
Simple commands are being coded as part of the Github workflow. For high level commands, those are implemented using makefile targets or third party tools so they can be easily run locally to dev/test.