Add timeouts for commit hooks

[DaRacci]

trafficstars

This Pull Request closes #2546.

It changes the following:

• Adds timeouts to git hooks

I followed the checklist:

• [x] I added unittests
• [x] I ran make check without errors
• [x] I tested the overall application
• [x] I added an appropriate item to the changelog

[DaRacci]

Opening early as a draft.

Initial changes are working and have tests added for them just need to figure out how we are going to implement a timeout value, if thats user configuration or a default impl.

[DaRacci]

Was wanting to get some feedback on this before progressing further, is this the correct place to implement the timeout logic? @extrawurst

[extrawurst]

This would impact other users like Gitbutler. @Byron what do you think about this change?

[DaRacci]

Also worth mentioning as its done in this PR, I've changed the test shell shebang to use /usr/bin/env sh as this is a more widely accepted and allows distributions like NixOS to run the tests.

[DaRacci]

I've also noticed that while running tests that since i use the non POSIX Shell (nushell) that i need to prefix the command with SHELL=bash, i was wondering if it may be worth testing if the $SHELL is a known non compliant shell and trying to look for a default POSIX shell in the path?

[DaRacci]

Now that the implementation is solid how do i go about with setting the timeout, how do we expose configurable value for the user and should there be a default timeout?

[DaRacci]

@Byron I've updated the implementation and it is now inside git2-hooks, I've added new functions with suffixed _with_timeout for each hook but the run_hooks function has a breaking change having the timeout parameter added to it.

[DaRacci]

The last remaining thing to do is move the tests i had written over to the git2_hooks crate, even so the current tests in asyncgit should be able to cover most cases i think.

[DaRacci]

I was also thinking about the initial issue where the problem was an infinite wait because the hook was waiting for input, maybe a solution could be when a hook is running a new window is shown with the stdio from the hook and also allowing stdin, not sure if that would work how im thinking though.

[DaRacci]

I'll get some tests put into the git2-hooks crate and resolve these issue when I get some times on the weekend to do so, please let me know if there is anything else that should be looked into for when i get to it.

[Byron]

@Byron I've updated the implementation and it is now inside git2-hooks, I've added new functions with suffixed _with_timeout for each hook but the run_hooks function has a breaking change having the timeout parameter added to it.

The idea would be to leave the run_hooks() function alone, and have it call the _with_timeout() function internally with a zero-timeout. That way one trivially avoids the breaking change while providing the feature to those who are interested in it.

I was also thinking about the initial issue where the problem was an infinite wait because the hook was waiting for input, maybe a solution could be when a hook is running a new window is shown with the stdio from the hook and also allowing stdin, not sure if that would work how im thinking though.

I don't think this can be a solution, as hooking up stdin must be controlled by the caller. For now, I'd think that hooks inherit stdin from the calling process, and that should work fine even if these have no stdin, as hooks can detect this and even if not they would never be able to hang - reading from a closed file will immediately fail.

Nonetheless I agree that timeouts for hooks may be solving for 'buggy' hooks, and it might be better to fix those (or understand precisely why they maybe hang legitimately so that can be fixed on the side of git2-hooks instead).

[DaRacci]

The idea would be to leave the run_hooks() function alone, and have it call the _with_timeout() function internally with a zero-timeout. That way one trivially avoids the breaking change while providing the feature to those who are interested in it.

I've made this change so run_hooks is left alone functionally and there is now the with_timeout version.

I don't think this can be a solution, as hooking up stdin must be controlled by the caller. For now, I'd think that hooks inherit stdin from the calling process, and that should work fine even if these have no stdin, as hooks can detect this and even if not they would never be able to hang - reading from a closed file will immediately fail.

Nonetheless I agree that timeouts for hooks may be solving for 'buggy' hooks, and it might be better to fix those (or understand precisely why they maybe hang legitimately so that can be fixed on the side of git2-hooks instead).

I think for now its best to track this in a new issue / PR, this one is pretty complete and ready to go as it is.

[extrawurst]

@DaRacci please update with master

[DaRacci]

Apologies, I'm in the middle of building & swapping to a new computer I'll get back to this when I'm able to.

[DaRacci]

I've rebased and addressed most of the suggestions but there's some tests that seems to be failing at random that are unrelated to my changes as they still randomly fail or pass even on the master branch for me.