Drupal-console: Drupal Console remote aliases (--target) not working

[geerlingguy]

Drupal Console remote aliases not working

[ console ] Can't get remote aliases to work with Drupal VM (or anything else, really).

Problem/Motivation

I'm having a very hard time getting Drupal Console to use any of my site aliases, using rc16. I would like to run drupal [command] from my host computer on either a local VM (using Drupal VM).

I know this functionality _was_ working at some point (like rc12?) in the past... it seems like I can't get it to work at all with rc16.

How to reproduce

$ drupal --version
Drupal Console Launcher version 1.0.0-rc16

1. Install and bring up an instance of Drupal VM.
2. Run the command drupal --target=drupalvm.dev site:status.

$ drupal --target=drupalvm.dev site:status


 [ERROR] Command "site:status", is not a valid command name.

I followed the instructions in Drupal VM's documentation here: Drupal Console - Remote command execution.

And I verified that the file ~/.console/sites/drupalvm.yml is present on my host (just like is shown in the Drupal VM docs).

I can also reproduce this issue with other VMs on my machine—it's as if the --target=[target.env] is completely ignored with every command, because it still tries connecting to MySQL using the local settings.php file, and doesn't seem to take any longer than running drupal without --target...

Solution

Figure out why aliases aren't working.

[geerlingguy]

I can also get commands to work fine _inside_ Drupal VM, if I have drupalconsole in the installed_extras and run the drupal commands inside the docroot (e.g. in /var/www/drupalvm/drupal).

[nvaken]

Hi @geerlingguy, I've run against the same problems as you have.

I've dug into these and found out that the Drupal Console Launcher loads it's own instance of ConfigurationManager. The same ConfigurationManager get's instantiated again in Drupal Console Core. While that might not sounds as a major issue, the launcher's instance of ConfigurationManager does not contain the same data as the one in Drupal Console Core. This issue seems to originate that the $applicationDirectory in the launcher is the launcher's own directory and therefor does not pick up the config that is created in the Drupal install folder. In the core instance, it's created with the project folder as $applicationDirectory.

So, when you run drupal site:debug (which is a Drupal Console Core command) to see your configured sites, you will actually see the sites which should be valid for usage in --target. But, when you use --target (which is taken care of by the launcher) with that same site, it will not be able to find it.

I do see a few issues to overcome:

1. Make sure --target becomes more verbose, telling the user when it's not able to find a target. Now the output is extremely confusing. Might even want to show the user when it's trying to connect to the target.
2. Try to prevent ConfigurationManager from being loaded twice, preferably making it a singleton.
3. If 2 is not possible, make sure the $applicationDirectory is the same for both the launcher and core.

@jmolivas I think this might be labeled as a somewhat more critical issue?

[geerlingguy]

Note that @jmolivas posted a kind-of workaround for this issue, at least with Vagrant-based environments, using vagrant-exec: Executing Drupal Console commands on a project with DrupalVM using vagrant-exec plugin.

However, this bug still means I can't execute Drupal Console commands on any of my projects elsewhere (e.g. on cloud servers, Acquia Cloud, Raspberry Pis, etc.) without manually logging into those servers :(

[jmolivas]

@nvaken @geerlingguy I will take a look to the remote command execution of DrupalConsole.

[adriadrop]

Think the whole problem comes from not running "drupal init" on local machine to setup proper files locally, more on this here https://github.com/hechoendrupal/drupal-console/issues/3523#issuecomment-329674686

[jmolivas]

@adriadrop @geerlingguy I added a new page to the DC docs about Connecting to a virtual environment => https://docs.drupalconsole.com/en/alias/connecting-to-a-virtual-environment.html this may helps

[gaelg]

I tried vendor/bin/drupal -t=docker.default site:status. I get [ERROR] Command "site:status", is not a valid command name.

Here's my alias conf:
$ vendor/bin/drupal -t=docker.default debug:site docker.default
docker.default
user: drupal
port: '22'
type: container
root: /var/www/html
extra-options: 'docker-compose exec --user=82 php'

docker-compose exec --user=82 php vendor/bin/drupal site:status works but I'd better use an alias. What am I doing wrong?

[jmolivas]

@gaelg you should use the drupal global executable aka Launcher on the host machine https://docs.drupalconsole.com/en/getting/launcher.html in order to use aliases and remote command execution and instead of calling

vendor/bin/drupal -t=docker.default site:status

you should do:

drupal -t=docker.default site:status

[gaelg]

It's a bit late but I can confirm that this works. Thank you!

[nvaken]

Did not need to revisit this for a while since I haven't had the need to use --target untill now, but I still seem to be having these issues. When running drupal --target=production.default site:debug I just get local information, also, using an invalid target name still returns the same results. @jmolivas am I overlooking something? I'm using launcher 1.5.0 as well as 1.5.0 project console install.

$ drupal debug:site production.default
production.default
user: my_user
port: '22'
root: /home/users/my_user/application/current
host: my-ssh-server.ext
remote: true

[harold20]

It is no longer present using version 1.9.0