add a testCase annotation to the deployment containing the test case name when we attempt an attribute change
wait for that annotation to show up after we apply our kedacontroller, signifying that the controller processed the deployment
then we can check for the attribute we changed and make sure it handled it properly for our specific testcase
I'm not in love with this fix, but I think it should be dependable until we can make some deliberate decisions/refactors.
NOTE: The audit config tests don't work right either, but I only wiggled them a little bit, because they are harder to solve because the functionality they are testing is currently broken, i.e. you can't currently deconfigure audit, so you can't ever reset the operator to a "clean" state to try the next test case. (That has to do with how we calculate our manifestival changes from the previous manifest and not the base manifest, and how we only transform if our values are non-empty [1] [2] ). We can and probably should fix that later.
Checklist
[x] Commits are signed with Developer Certificate of Origin (DCO)
joelsmith
commented
4 weeks ago
This functionality test has been failing since we did our last bump.
It was honestly never really testing anything because it never waited for the deployments, we were mostly getting lucky and not checking errors. See this run for an example of the old "tests nothing and succeeds" behavior: https://github.com/kedacore/keda-olm-operator/actions/runs/8209089746/job/22472571935
This change is basically:
testCaseannotation to the deployment containing the test case name when we attempt an attribute changeI'm not in love with this fix, but I think it should be dependable until we can make some deliberate decisions/refactors.
NOTE: The audit config tests don't work right either, but I only wiggled them a little bit, because they are harder to solve because the functionality they are testing is currently broken, i.e. you can't currently deconfigure audit, so you can't ever reset the operator to a "clean" state to try the next test case. (That has to do with how we calculate our manifestival changes from the previous manifest and not the base manifest, and how we only transform if our values are non-empty [1] [2] ). We can and probably should fix that later.
Checklist
Fixes #