[chore] Functional tests v2 #949
Conversation
atoulme
force-pushed
the
add_e2e_tests
branch
3 times, most recently
from
0aac2af
to
bf72384
Compare
atoulme
force-pushed
the
add_e2e_tests
branch
3 times, most recently
from
86b61ed
to
ed0f61d
Compare
…pt to test trace auto-instrumentation
atoulme
force-pushed
the
add_e2e_tests
branch
2 times, most recently
from
ab27696
to
fa2d800
Compare
| .PHONY: cert-manager | ||
| cert-manager: cmctl | ||
| # Consider using cmctl to install the cert-manager once install command is not experimental | ||
| kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/${CERTMANAGER_VERSION}/cert-manager.yaml |
There was a problem hiding this comment.
is cert-manager installation for the operator webhook? if so, then can we just enable the cert-manager dependency when installing helm chart?
There was a problem hiding this comment.
No, that didn't work. I copied the cert-manager testing code from the operator project instead.
There was a problem hiding this comment.
Jina's suggestion should theoretically be plausible, I wonder if this a limitation of using kind in a GH workflow. This solution is acceptable for now.
The operator project runs tests in parallel using 1 kind cluster with the kuttl test framework which results in each test case getting a unique k8s namespace to run the test case in. Since you can only have 1 cert-manager per k8s cluster, the operator project runs 'make cert-manager' once when setting up the kind cluster before any tests are run.
There was a problem hiding this comment.
It really seemed like a weird ordering issue, as in the operator would be failing to get a cert and just hang there. It is probably because of the nature of the deployment, if you install cert-manager at the same time as the operator.
The good news is that we can patch this to use the cert-manager in the helm chart with a smaller delta.
Description:
add e2e tests that test cluster receiver metrics and an attempt to test trace auto-instrumentation.