Add timeouts for commit hooks

[DaRacci]

This Pull Request closes #2546.

It changes the following:

• Adds timeouts to git hooks

I followed the checklist:

• I added unittests
• I ran make check without errors
• I tested the overall application
• 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?

[cruessler]

From an implementation standpoint, this looks good. The only thing I would add is tests for non-zero timeouts (maybe that’s something you already planned or maybe I missed something).

[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?

[Byron]

Thanks for letting me know, @extrawurst.

The changes seem to not apply to git2-hooks, so wouldn't affect GitButler in its current form. However, that would change if timeouts would move into git2-hooks as I seem to be proposing :).

PS: I unsubscribed as this PR is relevant to me only once git2-hooks is involved. You can always ping me to change that.

[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.

[Byron]

Thanks a lot for the quick turnaround!

The new implementation definitely addresses the previous issue, and now the timeout has an actual effect on the hook.

When looking at git2-hooks exclusively, I am not sure I saw a test for this though.

[Byron]

Docs are missing.
Probably the crate could use a deny(missing_docs) as well.

[DaRacci]

I looked at adding deny(missing_docs) to the crate but there are a number of errors that are outside the scope of this PR.

[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.