pantheon-systems / terminus

The Pantheon CLI — a standalone utility for performing operations on the Pantheon Platform
https://pantheon.io
Other
318 stars 195 forks source link

Terminus needs option to output "working ..." text to cli on slow running commands #1727

Open finteractive opened 7 years ago

finteractive commented 7 years ago

When setting up a bash script for managing multiple sites with a custom upstream a number of commands will time out because terminus displays no output.

I'm noticed this these commands on larger sites:

terminus backup:create
terminus env:clone-content

My script does the following functions:

  1. Run a terminus env:wake to wake all environments.
  2. env:clone-content Live environment's content and files to Clone-Live environment.
  3. Clone-live is then env:clone-content to an internal QA environment (Used for visual regression testing vs Clone-live)
  4. Clone-live is then env:clone-content TEST environment (Used for Client's manual testing).

What Happens On large sites some longer running tasks time out.

[error]  cURL error 35: Unknown SSL protocol error in connection to terminus.pantheon.io:443  (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Even when they time out, the tasks complete, but it breaks my automated workflow. If the first clone-content command times out (Step2), the next clone-content will start running before the first is completed, resulting in corrupted files and/or database on steps 3 or 4.

Proposed solution. Add a terminus flag that can be used on all commands to output "Working ..." and have the dots change from 1 to 3 dots. (or perhaps make this the apply to the "slow" commands). This should stop the script from timing out

It sounds like like this issue is form the same source - https://github.com/pantheon-systems/terminus/issues/1672

azinck commented 7 years ago

I, too, get this error a lot. And it makes using Terminus almost impossible.

nstielau commented 7 years ago

@finteractive are you sure this is related to timeouts? To me it seems like it is just one request that fails due to SSL issues which fails the terminus command. Looking at the loop in #1738, we are periodically checking of the Workflow status, so the longer the Workflow the more calls are made and the more likely one of them is to fail.