Deprecate the start.sh script in favor of using the underlying tools
grayside opened this issue · 3 comments
The start.sh script was created early in establishing the environment sub-generator's original code. The intention:
- Work out all the details necessary to get a new local development environment from 0 to running as a single step.
- Guarantee all the steps used to set up an environment on a local machine match the steps used by Jenkins for CI and deploying QA environments.
- Create a single place to capture all the wacky gyrations needed to make containerized Drupal work the way we want it to.
- Demonstrate to developers the "core path" to interacting with the containers to perform the basic operations of working with this setup.
However, over time, a few more things came up, sophisticated error handling, options to do different things, extra comments to further explain different steps and what their output meant... until the start.sh script became something developers felt they had to learn to use, instead of a collection of steps they could feel comfortable with and use the script as a sort of convoluted alias.
This has had a number of downsides:
- Many developers are using the start.sh script instead of using docker-compose, grunt, composer, and drush when the specific tool is called for. This means the helper script is getting in the way of the learnability of standard tools and how they play together.
- The start.sh script is large & convoluted looking, but is really fairly simple. This misleads developers into thinking setup is complicated than it is.
- Some of the complexity that does exist came from a time when Docker, Outrigger, or Outrigger Drupal were less stable.
- Some of the complexity that does exist came from a simpler time, when local environments were always a simpler case than QA environments. With the addition of tools such as Unison to Outrigger, that is no longer necessarily the case.
As a breaking change, it's time to remove start.sh.
- Replace start.sh contents with a few nice deprecation warnings.
- Make sure the generated outrigger commands cover all the essential pieces of the start.sh script. This should adequately take over the discoverability/learnability function the start.sh script had.
- Be comfortable with ~5 clear steps to deploy an environment instead of 1 multi-functional step, and incorporate those into the necessary Jenkins job templates.
What about existing projects?
Projects can continue to use the start.sh script they have, or not, as they like. As with any decision to run the generator with --replay to collect optional updates, there are things any project will need to skip. This will be a bigger, more obvious one, but the worst case scenario is that a project ends up with 3 sources of truth: the start.sh script, the rig project setup script, and whatever happens in Jenkins. That seems easy enough to rectify for a project willing to be "progressive" about updating code from the generator.
Do you have any idea how many people actually use --replay? I have my guess, but I'm wondering what you think.
I imagine it is used quarterly for real. EDIT: By the total community of users.
Done!