-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql-sync ignores drush-script definition in alias #2255
Comments
Seems so. Please also provide the Drush version and contents of |
Drush version: 8.1.2
|
I suspect that the sql-conf is being issued by the target machine during
the sql-dump call. so MYSCRIPT is totally unknown there. If you want to
affect how this sql-conf runs, you may have to do some drushrc work at
@remote.site.
|
Oh, you posted that sql-dump is working already. Can you post the full verbose output of that. Curious how the |
It's interesting, sql-dump doesn't require sql-conf, here is the full log:
|
Thanks. can you post full verbose log for |
Is there Drush 8.1.2 on both remote and local? To be sure, you could post output of drush status for each machine |
Yes, it's Drush 8.1.2 on both hosts, local and remote. The log for sql-sync looks like this:
|
Thanks. During drush_sqlsync_sql_sync_validate(), we get to this line which issues a sql-conf call to remote. Someone needs to debug why that call sql-conf call doesn't happen with MYSCRIPT. |
I'll have a look. |
So here is my analysis: When calling
This is called from Then, in contrast,
So this is where e.g. `drush-script' is missing. I'm not exactly sure how to fix this, because in drush_do_command_redispatch() there is a lot of magic going on to build the correct What I did to fix this for my current context is to replace
in drush_sitealias_add_db_settings() with
But I can imagine that this is probably not the correct way to go about this. |
Great analysis. Maybe @greg-1-anderson has some thoughts here. The right answer might be "wait for an upcoming site alias rewrite" |
One workaround would be to remove the database validation in drush_sqlsync_sql_sync_validate(). Thats the only reason we call sql-conf during sql-sync |
Interesting idea, in fact I could certainly include the database settings in my alias file as they get auto-generated by Ansible already and it wouldn't be difficult to add that piece of information as well. THat would prevent that step too if I'm reading the code correctly. |
I'm working with Acquia Factory Cloud, and hit this issue. Removing the validation does the job, ie, commenting:
although this is not a good fix obvs. I'll have a look and see if I can come with a patch |
One can make it work by passing correct parameters in alias: For drush 8.x path to drush script should be in [path-aliases] [''%drush-script']
For drush 9.x:
Note that you have to add options: path-aliases too. |
In Drush 9, nothing in the path-aliases context should affect drush-script, and drush-script should never begin with a |
This is work around I would say. includes/command.inc
The problem is that exportConfig remap only 'user', 'host', 'root', 'uri', other options are lost. AliasRecord.php
One can make a workaround by putting drush 8 parameters in options like this: remote.alias.yml
|
From your diagnosis above, it sounds like perhaps Drush should be remapping from paths.drush-script to options.path-aliases.%drush-script. However, think we already have a passing test that demonstrates that this is passed through correctly. Are you using the latest HEAD of master? |
You are right, it is fixed in master. |
In my aliases for remote hosts I do have the
drush-script
being defined which is used instead ofdrush
when building the command to be executed. This is working for all drush commands except the sql-sync command.So, when I call
drush @remote.site sql-dump --result-file=/tmp/test.sql
, this is working correctly and when using debug, I can see that this is being executed:You can see that
MYSCRIPT
is being executed.However, when I call
drush sql-sync @remote.site @local.site
this is being ignored and drush is being called instead of MYSCRIPT:That looks like a bug, isn't it?
The text was updated successfully, but these errors were encountered: