Generalize Container/Host Task execution location logic

[jameswilson]

Refactor the “where to execute this task?” logic out from Spark\Robo\Plugin\Commands\DrushCommand so that any Robo command inside spark can leverage it. This is a blocker for the GDPR dump sanitization task.

One approach would amount to moving the "isContainer" variable up to Spark\Robo\Tasks, and changing how the task execution code works in Tasks to take the container name and "isContaner" logic into account.

Here is how we're current using isContainer:

spark/src/Robo/Plugin/Commands/DrushCommands.php

Lines 30 to 43 in 38f1989

	if ($this->isContainer) {
	$this->say('🚢 Running inside the PHP container');
	$this->taskDockerComposeExecute()
	->file($this->dockerComposeFile)
	->projectName($this->config->get('name'))
	->setContainer(' php')
	->exec($command)
	->disablePseudoTty()
	->run();
	}
	else {
	$this->say('💻 Running locally');
	$this->taskExec($command)->run();
	}

Another challenge will be figuring out how to generalize certain caveats, like the execution directory, which appears to be different when inside the container versus outside. In this snippet we are changing both the webroot location as well as the path to the command binary drush when inside the container.

spark/src/Robo/Plugin/Commands/DrushCommands.php

Lines 13 to 23 in 38f1989

	private function prepare() {
	$this->isContainer = $this->containerExists('php');
	if ($this->isContainer) {
	$this->drush = '../vendor/bin/drush';
	$this->webRoot = '.';
	}
	else {
	$this->drush = $this->workDir . '/vendor/bin/drush';
	}
	$this->commandBase = sprintf('%s --root=%s', $this->drush, $this->webRoot);
	}

/cc @balintk @brants

[jameswilson]

Would it make sense to have a general way for Command files to override or instantiate their own default container name where their tasks should be run?

[jameswilson]

Eg the DrushCommand.php constructor would set $this->container = 'php'; the DbCommand.php constructor would set $this->container = 'db';