Refactor git.Command.Run*, introduce RunWithContextString and RunWithContextBytes

[wxiaoguang]

This PR follows

• replace all git.Command.RunInPipeline... with RunWithContext #18553

Introduce RunWithContextString and RunWithContextBytes to help the refactoring. Add related unit tests. They keep the same behavior to save stderr into err.Error() as RunInXxx before.

Remove RunInDirTimeoutPipeline RunInDirTimeoutFullPipeline RunInDirTimeout RunInDirTimeoutEnv RunInDirPipeline RunInDirFullPipeline RunTimeout, RunInDirTimeoutEnvPipeline, RunInDirTimeoutEnvFullPipeline, RunInDirTimeoutEnvFullPipelineFunc.

Then remaining RunInDir RunInDirBytes RunInDirWithEnv can be easily refactored in next PR with a simple search & replace:

• before: stdout, err := RunInDir(path)
• next: stdout, _, err := RunWithContextString(&git.RunContext{Dir:path})

Other changes:

1. When timeout <= 0, use default. Because timeout==0 is meaningless and could cause bugs. And now many functions becomes more simple, eg: GitGcRepos 9 lines to 1 line. Fsck 6 lines to 1 line.
2. Only set defaultCommandExecutionTimeout when the option setting.Git.Timeout.Default > 0

---

Now this PR is +127 −126 with more unit tests

[Gusted]

Seems like there are some user-defined timeouts being passed to this function, I'm not sure that in the middle of normal operations a panic should occur from a process...

Reference:

gitea/services/mailer/mailer.go

Line 276 in a82fd98

ctx, _, finished := process.GetManager().AddContextTimeout(graceful.GetManager().HammerContext(), setting.MailService.SendmailTimeout, desc)

[6543]

hm that would mean we either should fail on gitea init or put out a warn and ignore this setting

[wxiaoguang]

@Gusted

When passing timeout<=0 into AddContextTimeout:

• Before: then the context is cancelled immediately (a non-obvious bug, which may lead to more strange problems)
• Now: a panic is reported as early as possible, when we catch the bug and can fix it.

From my experience, in a big and complex system, everything should be defined as a clear behavior, if there is something unexpected happening, the error should be reported in the first time. We should always expose mistakes, instead of hiding mistakes.

So I think this new mechanism is better and more stable, this refactoring is only done in 1.17 and we have enough time to catch more bugs in future.

And fortunately, the SendmailTimeout has a default value: SendmailTimeout: sec.Key("SENDMAIL_TIMEOUT").MustDuration(5 * time.Minute),, so there will be no problem now. As an exmple, if user set SendmailTimeout=-1 in old code, the user only sees some non-sense errors like context cancelled. Now, the user knows that the timeout is wrong. And when he reports the bug to gitea issues, the panic message is also very clear for maintainers.

[lunny]

Or we could ignore the timeout context if timeout <= 0 but not panic

[wxiaoguang]

No, ignoring non-sense values in low-level frameworks is wrong. Many Go functions also panic if there is an invalid input.

[Gusted]

And when he reports the bug to gitea issues, the panic message is also very clear for maintainers.

I think we should prevent such issues from being reported. I'm not sure at which level the context cancelled are being reported to the admin, but otherwise it might be their "first time" that they observe that their configuration is incorrect. I think we should have a little note in the 1.17 announcement that a negative timeout can lead to panics and errors and that 0 should be used instead.

[Gusted]

Many Go functions also panic if there is an invalid input.

Many were written without being able to return errors, and given they don't want to break backwards compatibility, they instead panic.

[wxiaoguang]

And when he reports the bug to gitea issues, the panic message is also very clear for maintainers.

I think we should prevent such issues from being reported. I'm not sure at which level the context cancelled are being reported to the admin, but otherwise it might be their "first time" that they observe that their configuration is incorrect. I think we should have a little note in the 1.17 announcement that a negative timeout can lead to panics and errors and that 0 should be used instead.

Why do we need to mention that? If users were using -1 or 0, how can their system work correctly? And 0 is also incorrect for a timeout, it should be handled by Gitea's setting module to set to a default timeout, this work can not be done automatically.

[Gusted]

Why do we need to mention that? If users were using -1 or 0, how can their system work correctly?

I have no clue, but from what I've learned is that people can somehow survive with incorrect configurations without noticing. Anyhow, approving.

[wxiaoguang]

To be clear:

If a user were using -1 or 0, and their system works correctly, after this PR, nothing changes. Because these values were processed to defaults correctly by Gitea already.

If a user were using -1 or 0 and their system didn't work correctly, before this PR they knew nothing, after this PR they know that there is something wrong. That's a improvement.

ps: I agree "people can somehow survive with incorrect configurations without noticing.", however, once they meet some errors and report "bugs", it makes maintainers frustrated ..... nobody can guess what's wrong on user side if mistakes are hidden. We really need a clear system 😊

[wxiaoguang]

Let's merge and try. If the panic is too annoying, then let's locate the root case why such impossible case happens and find proper solutions. Personally speaking I have confidence about the stability.