Open jameswilson opened 6 years ago
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?
Eg the DrushCommand.php constructor would set $this->container = 'php'; the DbCommand.php constructor would set $this->container = 'db';
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:
https://github.com/BluesparkLabs/spark/blob/38f19897a4f8db2e2e0e5e6c74646710072fa04c/src/Robo/Plugin/Commands/DrushCommands.php#L30-L43
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.https://github.com/BluesparkLabs/spark/blob/38f19897a4f8db2e2e0e5e6c74646710072fa04c/src/Robo/Plugin/Commands/DrushCommands.php#L13-L23
/cc @balintk @brants