Allow cleaning up when test finished OK or FAILED

[aaguilartablada]

Feature Description

I'd like to be able to tell the operator to clean K6 objects when the test is OK and not when the test has FAILED as I want to debug and I can't do it if cleaning process is performed always when configured.

Suggested Solution (optional)

The suggested solution is giving more possibilities to 'cleanup' property. The idea is 'cleanup' can be set to:

• 'post' if you want to delete K6 object when the test is over regardless of whether it has finished successfully or not (current behavior).
• 'whenOk' if you want to delete K6 object when the test is over and it has finished successfully.
• 'whenFailed' if you want to delete K6 object when the test is over and it has finished with error.

Already existing or connected issues / PRs (optional)

#276

[yorugac]

@aaguilartablada, thank you! This problem is related to something I've been pondering lately myself; I agree we should improve this 👍
Somewhat related issue: #260

Going by your PR, it seems like you already have an API suggestion: could you please add it to the issue description first? Thanks!

[yorugac]

'post' if you want to delete K6 object when the test is over regardless of whether it has finished successfully or not (current behavior).
'whenOk' if you want to delete K6 object when the test is over and it has finished successfully.
'whenFailed' if you want to delete K6 object when the test is over and it has finished with error.

This looks somewhat redundant actually: the described use case with leaving resource only on error makes sense, but in which cases one would want to use "whenFailed"? I suggest to have instead these:

1. cleanup: "post" - clean up all test runs
2. cleanup: "success" - clean up only successful test runs.

[yorugac]

I think it might be nice to have this feature for Cloud tests as well, esp. for the aborted by k6-operator tests; so that the user can investigate what happened there. Currently, the PLZ test runs are all deleted (cleanup: "post"), even the aborted ones, and one is expected to have monitoring in place to figure it out post-factum.
cc @dgzlopes more UX 🙂