Operating on the assumptions that Drush recipe targets are Drush site aliases, i've set up aliases for my production and local sites. drush @example.local status
and drush @example.production status
both successfully bootstrap their sites and show the correct environment information.
However, this is the result when trying a target diff:
$ drush @example.local ddt @example.production
WD php: PDOException: SQLSTATE[28000] [1045] Access denied for user [error]
'drupal-example'@'localhost' (using password: YES) in db_select() (line
2523 of /vagrant/web/includes/database/database.inc).
PDOException: SQLSTATE[28000] [1045] Access denied for user 'drupal-gsl'@'localhost' (using password: YES) in db_select() (line 2523 of /vagrant/web/includes/database/database.inc).
Drush command terminated abnormally due to an unrecoverable error. [error]
The weird thing there is that is my *production* database user and my local (virtual machine— vagrant) site path.
And when i install drush_recipes on the production server in case that is a problem, and run the diff the other way, this is the result:
PHP Fatal error: Class 'Database' not found in /home/vagrant/.drush/drush_recipes/drush_recipes.drush.inc on line 678
Any thoughts on where i'm going wrong?
Comments
Comment #1
btopro CreditAttribution: btopro commentedso I'm not sure about the 1st error you described but the 2nd one...
Is something I recently added a @todo to the project about -- https://github.com/drupalprojects/drush_recipes/blob/7.x-1.x/drush_recip... is the area that is triggering that. We are able to handle DDT statements if you are in a root / on a server of the first alias.
So if you did drush @prod ddt @dev I believe it'll work.
Doing drush @dev ddt @prod (how do I turn dev into prod) will attempt to bootstrap a database off of a remote code-base which appears to the be the issue. There's something goofy around the notion of the Database global object not being set correctly but when run from drush sites on the same server it appears to work.
My todo points to how sql-sync works because it has to do some trickery to overcome this issue and not entirely sure how to deal with it yet unfortunately. Everything else associated with DDT SHOULD work leading up to that 1 part w/ selecting the db to bootstrap.
Help greatly appreciated on this one as I want to be able to do DDTs from anywhere as part of CI!
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedWe may not be able to do what sql-sync does, since I believe that just does a db dump and rsync it locally.
Comment #3
frederickjhHi!
I am trying to run the ddt comand on a install on docker using the @none and @self built in commands but this is not working. The database settings in settings.php are all done by environmental variables.
I am using Drude for this.
The database connection in settings.php looks like this:
This is how the Drude instruction say to configure the database settings.
I am using the Drude Shell Helper, dsh, to run the drush commands.
dsh drush dl drush_recipes
installed Drush Recipes in the cli container in the normal place for the root user, /root/.drush/drush_recipes/ .
As you can see in the terminal session below the default aliases are there but running a ddt with them does not work.
Any idea if this is related?
I hope it is as this was the only hit when searching on the error message.
Thanks!
Frederick
Comment #4
btopro CreditAttribution: btopro commentedWhat happens if you go the other direction? @self to @none ? Also are you in the drupal directory when you issue that because the alias won't know how to find it unless it's in the folder in question
Comment #5
frederickjhHi btopro!
Actually I tried that and it is in the terminal session above.
I tried this on a test server where it is using a normal sites/default/settings.php file without using variables. This is an normal Ubuntu server with Virtualmin, Apache, MySQL and PHP.
The error messages there look the same. Here is the terminal output plus version numbers from drush, composer, php, and Drupal.
Is there a problem when there is no Drush alias file? I just realized that both of these setups do not have one. Both the Docker container and the Ubuntu server. I have a Drush alias files on my laptop. I will have to test that and get back to you.
I hope that helps! If there is anything I can do to help troubleshoot this let me know.
God Bless!
Frederick
Comment #6
btopro CreditAttribution: btopro commentedsounds like the issue is that it's calling for a remote location. That's actually what this thread is about is that it can't bootstrap drupal correctly when not inside a drupal root when it issues the call. I'm guessing this is also the case here
Comment #7
frederickjhOk, adding an alias file allow me to run:
drush @ip04 ddt --test-run
on the server and get a recipe back.
If I try the same on the local machine I get:
env: drush: No such file or directory
I found that this was because the shell on the remote computer was set to sh not bash, so ~/.bashrc and that line that you add to it to allow drush to be found is not loaded by sh. Changing the shell to bash I get the following results:
I ran the following commands locally against the remote computer:
These produce identical output. Should there be a difference in the output?
The following command is producing the same error locally and on the remote computer both running Drush 7.0.0 installed with composer via the docs.drush.org website instructions.
Interestingly this is the command that you run in the Drush Recipes: ddt @none youtube video.