Drush aliases can't find document root

[chaseconklin]

With the latest release, v3.39.0, our team's drush aliases can't find the document root after regenerating. We have to manually add the /app directory before our document root to our alias files for the aliases to function properly. Our sites are currently running Drupal 8.6.7 and Drush 9.4.

[penance316]

I can confirm I have been the same issue for the last few weeks.
Drush 9.4.

My current workaround is to delete the line
root: web
from my yml aliases.

[hanoii]

Yup, same for me

[apeofbase]

Reverting back to 3.38.1 version of the CLI has temporarily resolved this issue while I wait for an official fix.

https://github.com/platformsh/platformsh-cli/releases/tag/v3.38.1

[pjcdawkins]

It seems the problem is if you run Drush inside a site that requires a different major version from your globally installed Drush.

For example, if you have Drush 9 installed as the user, but you run Drush inside a Drupal site that requires Drush 8.

With Drush 8 everywhere or Drush 9 everywhere, there is no problem.

At least that's what I get when I try to reproduce. The error with global 9 and local 8 is:

 [preflight] Class Drush\Log\Logger does not have a constructor, so you cannot pass any constructor arguments

[hanoii]

I have drush 8 globally and drush 9 local on most projects, but there's no error to be honest, it works, it's only that the root on the alias is wrong. Do we need to have it if removing it fixes it?

[baltazarz3]

I run into the same problem as hanoii, global drush v8 and one local project on v9. Removing the root worked, I hope this gets fixed on the next release.

[hanoii]

Removing it affects rsync, so it has to be /app/web as before or the proper path rather than just web

[baltazarz3]

Confirmed: removing the root breaks the rsync and /app/web worked.

[pjcdawkins]

I'm trying to track down the 'root' cause here. I don't see where in the source code of Drush 8 or 9 that an absolute path is required for the 'root', a relative one should work as it seems both do realpath() first then a chdir() later... and a relative path does work for me except when I have a global 9 and local 8 or vice versa. Trying to understand the conflict between them... 😞

[pjcdawkins]

... it turns out the important version number is the one installed on the remote.

Drush 9 (on the remote) doesn't handle the relative path. There is an alternative - it would replace ~/ with the home directory. Sadly, Drush 8 is the opposite: it does handle the relative path, yet it does not do the tilde expansion.

The CLI can't find the drush version on the remote, but it can guess, based on the drush version installed in the site locally.

[pjcdawkins]

Somehow in Drush 9 this method fails on web but not on the absolute /app/web or even the relative ../app/web:

https://github.com/webflo/drupal-finder/blob/1.1.0/src/DrupalFinder.php#L86

[pjcdawkins]

This is mostly resolved by #777 (released in v3.40.0) - but there would be issues with a locally installed 8 and remotely installed 9, until Drush 9 has been fixed to accept relative paths in all instances (see the DrupalFinder PR 40 referenced above).

[hanoii]

@pjcdawkins just updated to 3.40.2 and recreated on alias on a project. I have drush 8 globally but drush 9.5.2 on both remote and project local.

drush version locally gives 9.5.2.

A regular drush sql-sync gives me the following:

In Path.php line 587:
                                                  
  [InvalidArgumentException]                      
  The base path "~/web" is not an absolute path.  
                                                  

Exception trace:
 () at /Users/ariel/Sites/hanoii/charlas/vendor/webmozart/path-util/src/Path.php:587
 Webmozart\PathUtil\Path::makeAbsolute() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/site-alias/src/HostPath.php:148
 Consolidation\SiteAlias\HostPath->getPath() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/site-alias/src/HostPath.php:231
 Consolidation\SiteAlias\HostPath->fullyQualifiedPath() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/site-alias/src/HostPath.php:247
 Consolidation\SiteAlias\HostPath->fullyQualifiedPathPreservingTrailingSlash() at /Users/ariel/Sites/hanoii/charlas/vendor/drush/drush/src/Commands/core/RsyncCommands.php:63
 Drush\Commands\core\RsyncCommands->rsync() at n/a:n/a
 call_user_func_array() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/annotated-command/src/CommandProcessor.php:257
 Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/annotated-command/src/CommandProcessor.php:212
 Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/annotated-command/src/CommandProcessor.php:178
 Consolidation\AnnotatedCommand\CommandProcessor->process() at /Users/ariel/Sites/hanoii/charlas/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:302
 Consolidation\AnnotatedCommand\AnnotatedCommand->execute() at /Users/ariel/Sites/hanoii/charlas/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /Users/ariel/Sites/hanoii/charlas/vendor/symfony/console/Application.php:971
 Symfony\Component\Console\Application->doRunCommand() at /Users/ariel/Sites/hanoii/charlas/vendor/symfony/console/Application.php:248
 Symfony\Component\Console\Application->doRun() at /Users/ariel/Sites/hanoii/charlas/vendor/symfony/console/Application.php:148
 Symfony\Component\Console\Application->run() at /Users/ariel/Sites/hanoii/charlas/vendor/drush/drush/src/Runtime/Runtime.php:112
 Drush\Runtime\Runtime->doRun() at /Users/ariel/Sites/hanoii/charlas/vendor/drush/drush/src/Runtime/Runtime.php:41
 Drush\Runtime\Runtime->run() at /Users/ariel/Sites/hanoii/charlas/vendor/drush/drush/drush.php:66
 require() at /Users/ariel/Sites/hanoii/charlas/vendor/drush/drush/drush:4

Seems to fail on the rsync of the dump.

Is this the issue you mentioned? Why is that, shouldn't version 9 be used on both on this case?