Make refresh commands runnable inside container for ddev

[apotek]

As described in #204, we can't run robo refresh divorced from the host OS when using ddev because unfortunately the ddev-specific implementations are using ddev commands, which cannot be run inside the container.

Removing the reliance on those commands and using native drupal/drush instead, allows us to run the robo refresh sequence entirely within the service container, meaning the developer doesn't have to futz with php versions, composer etc, on the host OS.

Resolves #204

[apotek]

@mmatsoo / @mattdaniel Wondering if either of you have the bandwidth to look at this Usher change, allowing refresh to happen within the container instead of having to run it in the host OS context.

[mmatsoo]

👍 I left one comment for contemplation, but looks good.

[apotek]

I am going to add this to devops agenda or tech back end meeting of some sort so I can broadcast the implications of this change.

[apotek]

@mattdaniel I'd love your eyeballs on this at some point.

[apotek]

Run a comparison on an in-container database load versus using ddev import-db for a site like JFK.

@mattdaniel Makes the point that implementing this does not remove the possibility of using the ddev native database import.

@agarzola It is important to engineer our tooling so that it can be more agnostic, more composable. So the less we build in assumptions about lando or ddev into our tooling and can create implementation-neutral tooling, the better. So our composer commands should prefer to not mention ddev.

[apotek]

Going to hold off on merging this until the next devops council so we can broadcast the change and any potential fallout. Also not good to release this during time I am out of office.

[apotek]

We need a rollout plan for this to minimize disruptions.

1. When a site lead decided to update usher, what needs to be communicated to end users?
2. How to best add the .ddev/commands/web/robo command to each site?
3. Should this be a breaking usher version change? (ie, move from 4 to 5 and if we go from 4 to 5 should we also upgrade robo to v5?).

• Investigate if robo5 introduces any breaking changes.
• Decide on including a ddev "robo" command in each repo or as a ddev add-on
• Come up with boiler plate "README" for the update that each tech lead can use to change their README andn communicate procedure changes into their own project's README (also with our clients).

#! /bin/bash
## Description: Runs robo inside ddev
## Usage: robo
## Example: "ddev robo deploy:drupal"
./vendor/bin/robo $@