Using k6-operator v0.0.14, I create a TestRun resource with property “spec.paused” = “true”. Unexpectedly, the operator seems to ignore this property setting and instead executes the TestRun to completion.
My expectation is that the TestRun should remain in the “paused” state until I unpause the TestRun by changing property “spec.paused” to “false”.
Is this a bug or is my understanding of the expected behavior incorrect?
Hi @ron18219, paused is actually true by default. So if you set it to true, nothing changes. You can pass false there and then the runners should start as soon as they are up, without waiting for starter.
This is the same paused as in k6:
So it is the logic at the level of k6 runners, not that of k6-operator.
This can definitely be documented better Reference issue:
GitOps-deploy a workload containing a set of TestRun resources in a waiting state
Suspend GitOps management of the workload
Imperatively iterate over the in-cluster TestRun resources and trigger their execution one at a time using say a kubectl patch operation to change a property value or set a special annotation or label
GitOps-undeploy the workload
Is this possible with the current version of the operator? If not, should I open an issue for such a feature?
Imperatively iterate over the in-cluster TestRun resources and trigger their execution one at a time using say a kubectl patch operation to change a property value or set a special annotation or label
How is “imperatively iterate” implemented? It sounds like it isn’t part of GitOps workflow but and additional hack, which runs contrary to GitOps operations. Could you elaborate please?
Is this possible with the current version of the operator? If not, should I open an issue for such a feature?
This workflow, if I understood it correctly, is not currently supported by k6-operator. So yes, feel free to open a GH issue.
Rather than submit a request for a hack-related feature, WDYT about the following k6-operator feature request that I think adequately captures my requirement?
Orchestrate the serial execution of a set of TestRun resources. If one of the TestRun executions within the set fails, optionally terminate execution of the set of tests.
Hi @ron18219, yes, I believe that issue with Test Suite that you found is the closest to your case, among the existing ones. Could you please add details for your use case in the comment to that issue then? Like what your requirements would be and how test suite would help with that.
We didn’t make any decision about it yet, esp. given that test suites in k6 are WIP. So having all the info available in one place would be helpful.