Adding composer script for "cms-install"

[stevector]

The intention here is that different composer-based example repos will have different installation steps (WordPress, different install profiles, some installing with config_installer).

It makes sense to abstract the installation to a commonly named composer script that can be called by tools like https://github.com/pantheon-systems/terminus-build-tools-plugin. See https://github.com/pantheon-systems/terminus-build-tools-plugin/pull/3/files#r103558979

[greg-1-anderson]

Good idea. Maybe the circle.yml could call this method. Is parameter-passing going to be an issue here?

[stevector]

Yes, here? https://github.com/pantheon-systems/example-drops-8-composer/blob/master/circle.yml#L69

Is parameter-passing going to be an issue here?

Maybe, do composer scripts allow for additional params?

[greg-1-anderson]

Should work.

[greg-1-anderson]

Starting to write some tests for the Terminus Build Tools plugin last night, and was thinking about this. I think we should break out several steps of the process as Composer scripts:

• pantheon-create-site: When build-env:create-project is called
• pantheon-create-env: When build-env:create makes a new multidev site
• pantheon-reuse-env: When build-env:create finds an existing multidev, & does not make a new one
• pantheon-merge-env: When the multidev is merged into the master branch

By default, we should call composer cms-install from pantheon-create-site, import configuration in panthoen-create-env and pantheon-merge-env, and use Terminus to clone the database from dev in pantheon-reuse-env.

This way, we default to the "reuse database" workflow, and folks can customize their composer.json file if they want to do something else, e.g. the re-install-Drupal-for-every-test workflow.

[stevector]

@greg-1-anderson, just want to make sure I understand. So would pantheon-create-env be a composer script that is called locally (from inside CircleCI in the case of automation) which would then call Terminus commands to create the multidev dev, and then use terminus composer to call the cms-install script inside Pantheon?

That makes sense to me. I think having a standardized set of composer script names across repos will allow for needed variation within the steps. I am a little hesitant about the possibility of confusion that could come from composer scripts running locally to call remote composer scripts.

[greg-1-anderson]

Perhaps my naming conventions were off.

pantheon-create-env is called by the script that creates a multi-dev environment. It would be called by a script running on Circle to run another script running on Circle.

Perhaps these should be called pantheon-create-env-action or -notify or -hook?

The main purpose here is to keep the circle.yml script constant, and allow users to define the behavior of their project via composer scripts in their composer.json file.

[greg-1-anderson]

Maybe on-pantheon-create-env would be the most clear.

[stevector]

I like on-pantheon-create-env, but that makes me think we are colliding with what Quicksilver does since QS has a hook to respond to Multidev creation.

[greg-1-anderson]

Hmm. Deep philosophical questions.

If your "on-panetheon-create-env" script is only going to import your configuration options, then I would think that it would make a lot of sense to do this with a Quicksilver script, and do nothing extra in circle.yml / composer.json.

However, if your "on-pantheon-create-env" script is going to re-install Drupal from scratch and import your test fixtures, then it might be kind of annoying to have this happen when you created a new multidev from the dashboard, if your intention was to make a copy of the dev environment for ad-hoc testing.

I'm not sure I have the answer here; those are just a couple of use-cases to consider.

[greg-1-anderson]

Take a look at the current code diff here. This project now supports the following use-case:

• Install via build-env:create-project: standard profile is installed, and config_direct_save is enabled.
• Fiddle with your configuration. Export it via the admin UI (using config_direct_save).
• On next install, installation is done via configuration_installer. All of your config comes back.

Regarding parameter passing, if you define the following in a composer.json scripts section:

    "foo": [
      "echo",
      "echo"
    ],

And then run composer foo bar baz, you get:

> echo 'bar' 'baz'
bar baz
> echo 'bar' 'baz'
bar baz

In other words, all parameters are passed to every command in a compound script. This makes it inconvenient to move the current short installation script out of circle.yml into composer.json. We'd like to pass the parameters such as site name and admin password, which are defined as environment variables in the Circle UI, so this feature is not lost by the refactor. We could do that by placing the install instructions in a short script, and call the script from composer.json. I'd rather avoid adding another script here -- my goal is actually to get down to zero scripts in the template projects, if possible. In addition to that problem, we also need to consider what we should do if the user wants to run composer cms-install directly from the shell -- could be a useful thing to do, to reset a site back to its default configuration. Not sure we should try to solve the problem of making the default installation values available to the user from their shell, since these values contain secrets, & are therefore best stored in the Circle environment variables.

I'd like it if Drush would just do the chmods (see: drush-ops/drush#2664), but historically it avoids that operation. We'll see how that comes out.

I tend to think that it would be reasonable to have Drush automatically switch to the config_installer if the profile is not specified, and configuration exists in the sync directory, and the config_installer exists. Heuristics for selecting the profile already exists. I'm not sure how to handle enabling config_direct_save in this scenario, though. I think this is an important feature, and I don't want to provide our own installation profile here. Of course, if folks switch to their own profile, they'll have to add and enable config_direct_save anyway, so maybe I should resign myself to documenting this step. I'd prefer to do this in a 'how to use a different profile' document, though, and keep the number of steps required to get started with the standard profile at an absolute minimum.

So, in summary, it is currently working better to do the installation steps in circle.yml rather than composer.json. However, this leaves us with the original problem that the installation steps in circle.yml are not readily available to be called by build-env:create-project. Maybe the best thing to do would be to force the very first build to always happen on the dev environment. If we did that, then build-env:create-project wouldn't need to run site-install at all.