Handling of interrupt signal during long running tests

[aservedio]

What do you want to see?

Hello.

Before anything, I'm a happy new user of the e2e-framework and I'm enjoying its usage and results. Great work!

I'm opening this request to inquire about the handling interrupt signal for long running tests. Basically I would love that if a test run is interrupted, it stops processing features and calls its Teardown and Finish functions, just like when one of the feature test fails.

Looking at issues, examples and code, the closest thing I found was that I could provide my own context but other then that I did not find anything that could help this objective, and I'm not sure it makes sense considering it never came up until now.

At first glance I'm guessing some modifications to the env.processTests function among other things would be a start.

Thoughts?

Thanks! :)

Extra Labels

No response

[vladimirvivien]

@aservedio thanks for pointing this out.
Right now there is weak signal handling in the code even though the context propagates everywhere.
I think it's a good idea to finally revisit this and add proper signal handling.

cc @harshanarayana

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale