Usage of tf.Errorf
breml opened this issue · comments
In the build/build.go for this repository, tf.Errorf is used to handle errors in the Tasks (https://github.com/goyek/goyek/blob/main/build/build.go#L72 and https://github.com/goyek/goyek/blob/main/build/build.go#L87). If I understand the working of tf.Errorf correctly, it does not immediately stop the execution of the task, but only mark it as failed (as described in https://github.com/goyek/goyek/blob/main/tf.go#L61-L65 and https://github.com/goyek/goyek/blob/main/tf.go#L72-L75.
Therefore, the commands (e.g. gofumports and golangci-lint are still executed, even if the the installation of said commands has failed. In my opinion, this does not really make sense. So I wonder in which cases Errorf might be used and if it would make more sense to stop the task execution also with Errorf (and not only with Fatalf). I understand, that this would change the behavior in comparison to the testing.T package, but I feel, that in a build tool it rarely makes sense to continue after an error occured, or do you have some good examples?
Make also stops after an error and often I see the so called "strict mode" enabled in bash scripts used in build pipelines (set -euo pipefail or similar), where the script is also ended on the first error.
@breml Thanks. It is a bug. tf.Fatalf should be used
👍🏻
And what are your thoughts about the value of Errorf? Do you have some good use cases, when to use it?
I normally try to avoid Fatal methods (e.g. log.Fatal) because they perform a hard exit (os.Exit(1)), which prevents the defered functions from running. I understand, that in the case of goyek, this is not the case (because of the usage of runtime.Goexit()). From a user experience (code reader) point of view, I would expect Errorf to be the thing I normally use and I would expect it end the task at this point.
Here is a practical example where Errorf helped me: https://github.com/pellared/go-build-pipeline-demo/blob/e039eb3bc9d06c5573cd2eb58cd00d5f9226e31a/taskflow/build/main.go#L58-L63 . It runs the test coverage HTML report even if the tests fail
I think that https://github.com/goyek/goyek/blob/main/build/build.go#L110-L118 and https://github.com/goyek/goyek/blob/main/build/build.go#L133-L145 are another examples where we want to get the most detailed error message from multiple commands.
log.Fatal is working differently than t.Fatalf. And goyek's works like one from testing package
I have created a PR thanks to your feedback: #64