Drush site alias commands stop working with version 12

[lhridley]

Describe the bug
Drush site alias commands that worked with Drush 11 are now not working with Drush 12.

To Reproduce
Upgraded drush install to Drush 12

Expected behavior
Executing drush @self.live status would return a status listing for the site defined for the alias @self.live

Actual behavior
Command returned an exit code 127 (command not found)

Workaround
Is there another way to do the desired action?

System Configuration

Q	A
Drush version?	12.2.0.0
Drupal version?	10.0.8
PHP version	8.1
OS?	Mac Local, Linux on remote server

We have drush-installer installed in the global path on the remote server.

Additional information
Running command with Drush 11 installed passing verbose flags reveals that the shell command executed by Drush is:

ssh -t -o PasswordAuthentication=no <username>@<ip_address> 'drush status -vvv --uri=https://my.website.com --root=/home/forge/my.website.com/public <== executes drush successfully on remote server

Running command with Drush 12 installed passing verbose flags reveals that shell command executed by Drush is:

ssh -t -o PasswordAuthentication=no <username>@<ip_address> '/home/forge/bin/drush status -vvv --uri=https://my.website.com <== fails to execute on remote server

The site alias file did not change, only the version of drush installed.

Drush alias file (./drush/sites/self.site.yml):

live:
  host: <ip_address>
  user: <username>
  root: /home/forge/my.website.com/public
  uri: https://my.website.com
stage:
  host: <ip_address>
  user: <username>
  root: /home/forge/staging.my.website.com/public
  uri: https://staging.my.website.com

Two observations:

1. --root=/home/forge/my.website.com/public is not being passed into the drush command
2. The path to the drush installation is not picking up the location of the project specific drush install (probably because of --root not being passed)

[greg-1-anderson]

Does this command work, if you run it manually?

ssh -t -o PasswordAuthentication=no <username>@<ip_address> '/home/forge/vendor/bin/drush status -vvv --uri=https://my.website.com 

If not, what is the path to the site-local Drush in your remote Drupal site?

[lhridley]

That command will not work because drush is not located at that path, it is located in the vendor/bin directory of the local site installation.

In troubleshooting this after opening this ticket, I did determine that if the path to the drush-script is explicitely specified in the site alias file (which means that we are bypassing the drush launcher script (which we do have installed), the site aliases work again.

Guess this means that drush-launcher is not compatible with Drush 12.

[greg-1-anderson]

It is true that drush-launcher is not presently compatible with Drush 12.

Drush 12 also adds the requirement that the remote Drush be a site-local Drush. It should assume that Drush is located in vendor/bin on your remote site, but your initial report showed that Drush was trying to find it in bin. (n.b. the command I asked you to run was different from the one that you reported as not working only in the location of Drush, which I manually changed from bin to vendor/bin.)

You didn't show drush-script in use in your initial report, but in your most recent comment you imply that you might be using it. The existence of drush-script is relevant to Drush's behavior here.

[lhridley]

I think this can be closed, since adding the specific path to the local drush install for each environment defined in the self.site.yml file rectified the problem. But, now this is documented for anyone else that encounters this issue.

Thanks @greg-1-anderson !

[greg-1-anderson]

What did you change to fix it? Is your site local Drush located at vendor/bin, or somewhere else?

[lhridley]

The site local drush is in "vendor/bin", I added the following to the drush aliases:

paths:
    drush-script: '/home/forge/<my.website.com>/public/vendor/bin/drush'

[greg-1-anderson]

Yes, that workaround will be necessary if your site has the project root at the docroot. It is recommended to put vendor outside of the docroot, e.g. with Drush located at '/home/forge/<my.website.com>/vendor/bin/drush'

[joelpittet]

I'm running into this drush script being incorrect too:

bash: line 1: /var/www/bin/drush: No such file or directory

The drush-script workaround mentioned above works.

  paths:
    drush-script: '/var/www/PROJECT_ROOT/vendor/bin/drush'

@greg-1-anderson Do you happen to know where/how that path is derived? I'll dig a bit

[joelpittet]

Tracking it down, seems like the problem happens in
\Drush\SiteAlias\ProcessManager::relativePathToVendorBinDrush

[joelpittet]

What that translates to for me:

prod:
  host: www.example.org
  user: www
  root: /var/www/SITE/current # (PROJECT ROOT)
  uri: https://www.example.org

When this runs to join the root and relative path:
Path::join($siteAlias->root(), $this->relativePathToVendorBinDrush());
vendor/drush/drush/src/SiteAlias/ProcessManager.php:73

That ../../bin in the above screenshot cuts out the SITE/current and even if I put the root to the Web Root:
/var/www/SITE/current/web # (Web ROOT)

It's still the wrong directory.

Am I doing something wrong in my interpretation of what root is?

[joelpittet]

Luckily xdebug allowed me to find the issue was the relative directory wasn’t correct when applied to the remote site alias.

runtime.project seemed to match better with the goal in the docblock of the method changed in that PR and the only available variable that did… but one thing I’ll note the site alias's root needs to be the project root, not the web/doc root (unless that’s where you’re vendor directory is…) I had my root in the site alias set to the webroot for Drush 11, and it needed to change...

The example is not clear what root is.
https://github.com/drush-ops/drush/blob/12.x/examples/example.site.yml#L9