Inject options from core:rsync and sql:sync alias parameters.

[greg-1-anderson]

Includes tests for both, and documentation in example.aliases.yml.

[weitzman]

consider adding docs to example.drush.yml and/or example.aliases.yml.

[greg-1-anderson]

Right now I am entombed in the hellish quagmire called backend invoke, which resists divulging the secret of drush-script.

[greg-1-anderson]

Ah. $site_alias_record->legacyRecord() converts things back into the form backend invoke expects, but it leaves off some critical information, like drush-script and ssh-options.

[weitzman]

I'll test this and possibly add more feedback. Thanks for your hard work here (and Consolidation).

My one thought is to pause and ask if we really need this alias-parameters feature. It looks analogous to the source-/target- prefixes of old. That feature was little used. My thinking is that folks can get used to the rule that command specific options will be honored depending where the command runs. That is:

1. drush sql-sync @foo @bar. local command-specific is honored
2. drush @bar sql-sync @foo @self. @bar's command-specific is honored

[weitzman]

can we add config-pull to this list?

[greg-1-anderson]

1. drush sql-sync @foo @bar. local command-specific is honored

Perhaps in this scenario, if we also took the command-specific options from @foo and @bar, that might be sufficient. I used to use source-command-specific and target-command-specific to handle use cases that config split uses now. With rsync, this feature could be useful to exclude a path when an alias is a target but not the source, or visa-versa.

This feature only takes a small amount of code now, so it shouldn't be too hard to maintain. I'm not convinced that it's critical, but I'm reluctant to give it up. Maybe take a survey and see if it is used?

[bar]

@greg-1-anderson @weitzman please, don't use my handle to document your code :p

thanks

[greg-1-anderson]

Seems like it is safe to use @ without making an @-mention as long as the reference is inside of a code block. If we always embed alias references in code blocks, then we won't need to worry about sending spurious notifications to unrelated GitHub users.

[benjifisher]

Typo. :s/remot/remote/.

[geek-merlin]

FTR from #5675:

My one thought is to pause and ask if we really need this alias-parameters feature.

For some use cases, default command options defined by aliases can NOT be replaced by default command options defined by drush config, because in a deployment use case, there is NO drush config before the first deployment.