Open stevector opened 7 years ago
Related to #14
A couple of words on goals.
Ultimately, for source code repositories, we would like to support:
For CI services, we would like to support:
And, of course, for each of these, we want to support:
That's plenty of permutations, and it doesn't even count the distributions!
For all of those service, it is beneficial to move code/scripts that will not be customized by the user out of composer.json / circle.yml (or equivalent) and into a Terminus plugin or Quicksilver script or an external repository that can be cloned, as suggested in the OP.
In instances where end-user customization is necessary, it's better to put it in composer.json rather than circle.yml, as there will be multiple variants of the CI script file (for different services), but all will use the same composer.json file.
I'm strongly in favor of this effort as a whole. Let's discuss each potential improvement in its own issue, as suggested. We should be cautious about optimizations that introduce complexity, and do so only where necessary.
Let's discuss each potential improvement in its own issue
Agreed.
We should be cautious about optimizations that introduce complexity, and do so only where necessary.
Double agreed.
I put my thoughts on testing the permutations over in https://github.com/pantheon-systems/terminus-build-tools-plugin/issues/5
Summary of discussion on reducing boilerplate.
composer require pantheon-systems/pantheon-components-d8
to make it run on Pantheon."composer require
after scaffolding the required site (which will be drupal-composer/drupal-project by default).require
section of composer.json:pantheon-components
project. The only function of this file is to make settings.php writable when Drush is used to re-install Drupal.There are some items that will need additional thought / work to migrate.
composer.json items
Some items in composer.json cannot be relocated to a dependency's composer.json file. For some of these, we can just presume that the parent project (drupal-composer/drupal-project) will have some strategy for the setting that we will simply adopt (e.g. minimum-stability
, prefer-stable
, etc.); we can document what values we recommend, but ultimately it would be up to the project-in-charge to decide what values should be used.
Drupal Scaffold
Currently, our example project includes the configuration settings that the drupal-scaffold tool uses to determine which files to scaffold. Currently, drupal-scaffold checks only the root-level composer.json for this file list. We could allow drupal-composer/drupal-project to scaffold the Drupal 8 files from the standard drupal.org repository, and then fix up the Pantheon customizations / additional files as a separate step handled by our project.
rvtraveller/qs-composer-installer
Composer installers need to be included from the top-level composer.json file. We'd probably need to make our pantheon-components
repository a Composer installer, and have it either include the qs-composer-installer functionality, or find some way to forward the necessary calls to our event hooks to a child component.
Installation steps
The Terminus Build Tools Plugin currently reads the drush site-install
command to run from the extras
section of the root composer.json project. If we made a generic project with all of our necessary additions, then we'd need to be able to generate the install command ourselves. At the moment, the only part that needs to be customized is the installation profile to install. We could add some logic to the build tools to find the profile by some metric, and add an option to specify the profile so that the user could override the decision the tool would make.
Configuration export
The Terminus Build Tools Plugin exports configuration at the end of the build:create:project
command; it currently finds the command to run from the extra
section of composer.json.
Commit Comment Scripts These scripts are currently referenced from the circle.yml script et. al. to add a comment back to the PR that caused a multidev environmnet to be created. These scripts could be moved into the Terminus Build Tools Plugin.
PR Workflow
We wouldn't need to support the PR workflow as part of an MVP for our pantheon-components
project; we could start off with the PR workflow as being something supported by the example drops-8 composer repository. Ultimately it would be nice if the PR workflow could be added to any project. Some / all of these operations could become part of the Pantheon platform instead.
composer build-assets
to allow folks to add their additional build steps (e.g. less or sass compile). We might need another way to do this.composer install
is currently part of the build-assets
step. We could presume that composer install
is always necessary and just run it.rvtraveller/qs-composer-installer
.Behat Tests
Presumably behat test templates are provided by the project that the user selects to install (contenta, lightning et. al.)
Looking at the composer installer documentation again, it looks like composer installers can perhaps be included from a sub-project, although the info in extras
often must be in the top-level composer.json. I have not confirmed.
This package looks like a promising boilerplate reducer: https://github.com/hussainweb/drupal-composer-helper
Although they are both less than 100 lines, both
composer.json
andcircle.yml
have a lot of complexity that we are likely to copy into other repos for WordPress, Drupal 7, and many Drupal distributions like Lightning and commerce. To make the maintenance of a growing number of Composer examples more sustainable, we should reevaluate dependencies and places code can be shared. I will make individual issues for specific topics likeinstaller-paths
config from composer.json and moving it to a package (since we are already relying an a Pantheon-specific package to provide Quicksilver installer-paths)