Parameters not passed when invokeCommand is used with @executeInDrupalVM

[bobbygryzynger]

My system information:

• Operating system type: macOS
• Operating system version: 10.12.5
• BLT version: 8.9.0

When I run invokeCommand on a custom command which uses the @executeInDrupalVM annotation:

/**
 * A command to run within the VM.
 *
 * @command my:dvm:command
 * @para string $param
 *   A command parameter.
 * @executeInDrupalVM
 */
public function myDVMCommand($param) {}

$this->invokeCommand('my:dvm:command' ['param' => $value]);

I get the following output:

Executing command my:dvm:command --define drush.alias=self inside of Drupal VM...

And I expected the parameter to be passed to my command:

Executing command my:dvm:command my_value --define drush.alias=self inside of Drupal VM...

[grasmash]

This is surprising to me-- There are certainly many cases in which we are successfully passing parameters to this method, and invoking that command in the VM.

[grasmash]

I am not able to reproduce this on 8.x.

  /**
   * Print "Hello world!" to the console.
   *
   * @command hello
   * @param string $planet
   * @executeInDrupalVm
   * @description This is an example command.
   */
  public function hello($planet) {
    $this->say("Hello world!");
    $this->invokeCommand('validate:phpcs:files', ['file_list' => $planet]);
  }

$ blt hello drush.wrapper
Executing command blt hello drush.wrapper --define drush.alias=self inside of Drupal VM...

[grasmash]

I noticed two things about your posting. First, your annotation is not in the correct case. The "M" in executeInDrupalVm should not be capitalized.

Second, you did not post commands that you ran on the CLI. Would you mind sharing it?

[grasmash]

Oh, I think I know your issue. You have a typo in the word param. The annotated command library needs this annotation to be correct in order to correctly parse the arguments for the command.

[bobbygryzynger]

@grasmash sorry, some of that is just copy pasta.

Here's the command stub faithfully copied:

  /**
   * Lints the theme's Javascript.
   *
   * @command theme:scripts:lint
   *
   * @param string $path
   *   An optional path to restrict linting to.
   *
   * @description Lints the theme's Javascript.
   * @executeInDrupalVm
   */
  public function lintScripts($path = '') {
    $task = $this->taskExec('gulp')
      ->arg('eslint');
    if (!empty($path)) {
      $task->option('path', $path);
    }
    $task->run()
      ->stopOnFail();
  }

[grasmash]

Can you share the full method, including the body? And, also the command that you ran on the CLI?

[bobbygryzynger]

@grasmash sure, I updated the content above.

If I put a print_r for $args in executeInDrupalVm I always get empty values. If I put a print_r($event->getInput()->getArguments()) at the top of the function I get:

> theme:scripts:lint
Array
(
    [command] => 
    [path] => path/to/file
)
Executing command blt theme:scripts:lint --define drush.alias=self inside of Drupal VM...
[warning] The xDebug extension is loaded. This will significantly decrease performance.
Array
(
    [command] => theme:scripts:lint
    [path] => 
)
[Exec] Running gulp eslint

This is when calling the following function in a Robo watch task:

$this->invokeCommand('theme:scripts:lint', ['path' => $path]);

[bobbygryzynger]

This is perhaps related, the watch method's signature is this:

  /**
   * Watches files, and validates and re-builds assets when source files change.
   *
   * @command theme:watch
   * @description Watches files, and validates and re-builds assets when source files change.
   */
  public function watch() {}

Note that it doesn't have the @executeInDrupalVm annotation.

The command I'm running then is blt theme:watch.

[bobbygryzynger]

If I use this to construct the command arguments in executeInDrupalVm, this begins to work as expected in my particular instance:

$args = $event->getInput()->getArguments();
...
foreach ($args as $arg) {
  $command_parts[] = $arg;
}

The order of arguments looks be preserved by $event->getInput()->getArguments() if I add additional parameters to my base command. I think $this->getCliArgs() gets the inital command arguments, not the ones passed to subseqent invokeCommand calls.

[grasmash]

Would you mind submitting a pull request with the improvement?

[bobbygryzynger]

@grasmash I've discovered this issue is particular to the Robo watch task. Closing this issue. I will open up a new issue that provides better steps for reproducing the behavior.