Increase BLT runserver step error checking/verbosity

[dpagini]

My system information:

• BLT version: 8.9.0-rc1

So on Travis, the drush "runserver" command executes in the repo root, and by default, the alias for ci is @self. I think the @self alias will really only work from the docroot, right? If I change it to be my local alias, that alias file has the URI specified, which is not valid on Travis.

I'm thinking that command needs to be run from the docroot (always? just on Travis?). Does this make sense, or am I missing something?

[grasmash]

Any taskDrush() command in BLT is automatically run from the docroot by default.

Let me take a look...

[grasmash]

Yeah it looks like that should be the case. Does your output say it's being run in the repo root?

[grasmash]

https://github.com/acquia/blt/blob/8.x/src/Robo/Hooks/WebServerHook.php#L51
https://github.com/acquia/blt/blob/8.x/src/Robo/Common/Executor.php#L86

[dpagini]

Hmm... sorry, this may be a false positive by me. It does say it's running the command from docroot. Need to keep investigating =/
My tests were running OK a week ago on BLT maybe beta5 or beta6, and now I'm having trouble again. Will update as I find more.

[dpagini]

K, figured this out... this was my fault, but I'm hoping to turn this issue into a feature request...

I was making some more changes while testing BLT 8.9.0-rc1 and composer somehow reverted me to beta6 (before frontend task was added back in), so I was debugging the same error I had 2 weeks ago.

For a feature request, is there someway to increase the verbosity of the "runserver" commands? So basically, my code is executing...

$ blt tests:all --define drush.alias='${drush.aliases.ci}' --define tests.run-server=true --yes -v

The first thing this does is kill all previously running webservers. It then uses Drush to fire up a local server. That command was being completed successfully. Then it waits until it gets a response from http://127.0.0.1:8888 and eventually times out for me. The problem I was having was that my site was returning a PHP fatal error, but it just looked to me like the webserver wasnt running. I confirmed this by running in debug mode, starting up my webserver, and then running $ curl 'http://127.0.0.1:8888' and then could see the error.
Could the "wait for server" commands either check if there is an error somehow and just give more verbose output?

Going to change the name of this issue to reflect this new request...

[dpagini]

...and just thinking out loud here... maybe if the "wait" command runs and eventually can't connect, maybe the last thing it does is output the results of a basic curl command? I know it's specific to my problem, but I definitely spent a bunch of time debugging this twice (obviously my own fault) and thought this could maybe save people some time in the future?

[grasmash]

Yes I think that would be desirable behavior.