Display troubleshooting context if `update` command fails about gh-valet

[ethanis]

@luke-engle could we refactor the ProcessService#RunAndCaptureAsync method to be able to return both the text from the standard out/err streams (for example, by updating the method signature to return a tuple) and then the DockerService could use the returned value to see if the error contains a certain text?

[luke-engle]

@ethanis We may need to speed up our timeframe of when we wanted to rewrite the ProcessService in gh-valet 😓 I was looking into this and found that the error text we’re looking for (Error response from daemon: Get "https://ghcr.io/v2/": denied: denied) never actually gets captured. Well, technically it does get captured, but by the ReadStream method, which then immediately dumps it to the console and throws it away.

When the ProcessService detects a non-zero exit code:

        if (process.ExitCode != 0)
        {
            var error = await process.StandardError.ReadToEndAsync();
            throw new Exception(error);
        }

That error variable contains nothing every time, because the StandardError stream has already been consumed all the way to the end by the ReadStream method. That means there's currently no way for us to tell if someone isn't authorized or is using a token that is not permissive enough.

One way we could manage this is by maintaining a string or an array for StandardError by updating it in the ReadStream method, then if we hit an error, check if standard_error.Contains("Error response from daemon: Get "https://ghcr.io/v2/": denied: denied")? Not very performant if there happen to be a lot of errors, but I don't exactly expect that to be the case here - plus we'd only be doing this Contains check if we failed to authenticate with docker, which means output to standard error at that point should be minimal. What do you think?

(Sorry for the novel)

[luke-engle]

@ethanis That's a good point, I forgot about the RunAndCaptureAsync method! Although, I don't think we need to refactor it to return a tuple - it's already written to throw an exception with the stderr text if the process exits with a non-zero exit code. We can just try/catch and read it from the exception message. Does that sound good?

[ethanis]

It sounds like a bit of a smell to use exceptions to control the flow like that. Returning a tuple and letting the caller determine what to do with an error would be a cleaner, and more easily tested, approach. We could even add in the exit code to the tuple that's being returned 💭