Fix interactive UI for git push using password protected ssh key

[matscube]

Overview

This fix is related to Issue #369 .
When using password protected ssh key, password input is required when pushing with git push in the oco command, but there was a problem that the input could not be entered smoothly.
After confirming the operation, it seems that the password input UI is obstructed by the spinner. (It is not always input failure and there may be cases where you can enter it successfully)

Fix

Removed spinner.
It was judged that it is better not to sandwich the process that requires stdout/stdin with the user during command execution with spinner.

Behavior before and after the fix

• Before the fix

before_revision.mov

• After the fix

after_revision.mov

[di-sukharev]

@matscube so there is no way to keep the spinners?

[matscube]

@di-sukharev
I haven't checked yet if there is a way to keep the spinner while fixing it.
I think the easiest way is to replace the spinner with text, but I don't think it's good to lower the quality of the UI.
I'll look into it a little more to see if there is a way to keep the spinner.

[di-sukharev]

please 🙏

[di-sukharev]

there was a big refactoring in #391, not much got conflicted, but there is one file

btw for the spinner, is there a way we can tell that spinner will break things, like in this case with ssh password? we could then not start it and fallback to outro("loading") in this particular case

[matscube]

@di-sukharev

btw for the spinner, is there a way we can tell that spinner will break things, like in this case with ssh password? we could then not start it and fallback to outro("loading") in this particular case

If a child process is executed between spinner's start() and stop() methods, a problem like this is likely to occur. (For example, when executing a command using the execa library)

If the processing between start() and stop() is just a js processing, interactive input and output will not be executed, so it should work fine.

[di-sukharev]

@matscube

i see, so there is no way we know if the stdout gonna be interactive or not and thus we cant keep the spinner?

[matscube]

@di-sukharev

I can't say for sure without looking closely at the specifications of Node.js stdin/stdout and the implementation of execa and @clack/prompts libraries.

If the following technical hurdles can be overcome, it will be possible to achieve both spinner and input UI.

• Detecting standard input from child processes in Node.js
• Filtering specific stdout (such as messages prompting for password input) during command execution via execa and inserting arbitrary processing

I plan to investigate when I have time.

[di-sukharev]

Cant stop you if you are interested in this, but wdyt about just living it as a spinner for now, we still allow to input the password right and only formatting is a problem? If so, i’d leave it as is, bc password is a rare case

[matscube]

@di-sukharev
I don't think it's common to use a password-protected ssh key for git push.
Also, there are workarounds like setting OCO_GITPUSH to false or caching the password with ssh-add.
I'm not sure how long it will take to fix this problem cleanly, so for now, it seems better to leave it as a spinner as you suggest.
I'm going to close this PR for now, is that okay?

[di-sukharev]

@matscube lets close it, yep