Add option to wait for command to exit before restarting it

[invidian]

It would be nice if it would be possible to wait for Go command to exit by itself before starting it again. This would be useful when working with tests which requires cleanup to run.

[mitranim]

Currently gow broadcasts SIGTERM, immediately terminating the entire subprocess group. It sounds like you want "soft" termination that allows the program to run cleanup such as deferred calls. Traditionally, SIGINT serves this purpose. It would be nice to solve this case by providing an option to use SIGINT, followed by timeout, followed by SIGTERM. However, it seems that Go programs by default treat SIGINT similarly to SIGTERM: immediately terminate without running deferred calls or testing.TB.Cleanup. Which means we really need to wait for the program to exit on its own.

The simplest approach would be to add a boolean flag that causes gow to ignore FS events when the subprocess is running. On-demand restart via ^R should still work. Let me know if this sounds like desired behavior.

Would appreciate examples of tests that require cleanup. My preferred approach:

• When test must write to FS, use an OS temp directory.
• When reusing a directory, cleanup at the start of the test, not at the end.
• When using a database, run everything in a DB transaction, and rollback when done, to avoid pollung the DB.

This can be summed-up as "crash-only design", which works perfectly with gow.

[mitranim]

Implemented in a5bfab26a0e42ee646f0969ac3397e80e5e3b1df.

[invidian]

Hey @mitranim! Thanks for having a look into it and for gow in general! It's a absolute must have for me and it enables continuous testing workflow very easily.

I just pulled latest version, including commit you mentioned and I have some feedback:

• When test execution is complete, gow does not seem to react to ctrl+C, it only reacts after 3rd attempt. This occurs both with -l and without. I don't think that was the case previously?
• Changing file could still schedule another execution when file changes but lazy mode is enabled. So ideally no behavior would change except not sending the SIGTERM to the child process, but let it finish execution and then start it over.

Would appreciate examples of tests that require cleanup.

I agree with you on test strategies etc. I'm right now working with code which creates cloud resources and while working on integration tests for this code, I must create and cleanup some resources, hence my request.

[mitranim]

Single ctrl+c terminates the subprocess. Double ctrl+c within 1 second terminates gow. This behavior is unchanged from the previous version. In some earlier versions, single ctrl+c would terminate gow when the subprocess wasn't running, and this sounds like the behavior you expect. However, that behavior required you to check the status before hitting the hotkey, which is slower, requires more brain cycles, and has race conditions, compared to when the hotkey behavior is independent of the subprocess status.

I've considered if FS events during subprocess execution should schedule a restart, and decided against it. When using -c or -s, which I personally recommend, this would cause the previous result to flash and disappear, and then you'd have to wait again for the next cycle. Without an additional indicator that a restart is scheduled, the user has no way to know what to expect. It would create anxiety and waste time. My implementation avoids this. If you see that a test has started, you know 100% that you can wait for the end and read the results without them disappearing, wasting more CPU, or creating more side effects. If you want to restart afterwards, you can simply hit ctrl+r or save a file. I feel that this is a better overall UX. 🤷‍♀️

[invidian]

Thanks for explanation.

When using -c or -s, which I personally recommend, this would cause the previous result to flash and disappear, and then you'd have to wait again for the next cycle

Discarding of current result might be favored in some cases, for example when you realize that the code is wrong and you fix it. It seem to me that generally only the latest result actually matters, as it represents the result of the current state of the code.

Without an additional indicator that a restart is scheduled, the user has no way to know what to expect. It would create anxiety and waste time. My implementation avoids this. If you see that a test has started, you know 100% that you can wait for the end and read the results without them disappearing, wasting more CPU, or creating more side effects. If you want to restart afterwards, you can simply hit ctrl+r or save a file. I feel that this is a better overall UX. woman_shrugging

I agree, although it puts more work on the user, which means less automation and less usability.

Single ctrl+c terminates the subprocess. Double ctrl+c within 1 second terminates gow. This behavior is unchanged from the previous version. In some earlier versions, single ctrl+c would terminate gow when the subprocess wasn't running, and this sounds like the behavior you expect.

I'll provide more feedback once I do some testing with new version on the kinds of tests I talked about and see how usable it is. I can do it either here or in the new issue.

[mitranim]

Seems to be fixed 🙂