New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move operator integration test to its own directory and test separately. #4079
Conversation
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
script/e2e-test.sh
Outdated
installOrUpgradeKubeapps bitnami/kubeapps \ | ||
"--set" "featureFlags.operators=true" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a brilliant idea Michael!
Kubeapps resources are recreated to enable operators without the need to deploy the whole cluster again.
|
||
## Upgrade and run operator test | ||
# Operators are not supported in GKE 1.14 and flaky in 1.15, skipping test | ||
if [[ -z "${GKE_BRANCH-}" ]] && [[ -n "${TEST_OPERATORS-}" ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just wondering if skipping this test in GKE is still required (as now we are in more recent versions). Anyway, perhaps worths a separate PR not to be mixing up CI potentially breaking changes :P
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson <minelson@vmware.com>
Signed-off-by: Michael Nelson minelson@vmware.com
Description of the change
I wanted to ensure that we are testing Kubeapps in the default setup (ie. without any k8s API proxying) while also ensuring we still have the confidence of CI for basic operator support. Initially I was thinking we'd need to either run two jobs (not great, given the failures), but then realised we can simply run the main tests first, then update Kubeapps with the operator support and run the operator test at the end.
This enables the best of both worlds, and we can still switch off the operator test if we like (when a decision is made).
Benefits
All the main CI tests for Kubeapps run without any access to the k8s API.
Possible drawbacks
None that I can see.
Applicable issues
Additional information