Initial pass at Drupal 8 Capistrano platform.

[arh1]

Drupal 8 will require some Capistrano configuration changes. See also: #184

For the time being, the approach discussed is to create a new 'drupal8' platform. This PR provides a first pass at that inspired by a few projects' existing implementation.

Also note that Drupal 8 requires Drush 8. If the deployment target uses an older Drush, hackery ensues along the lines of:

• Include Drush 8 in your repository (hopefully via Composer)
• Edit the Drush rake file to point to your Drush 8 script
• Edit the Drush rake file and drupal8 platform file created above to fetch this new path value
• Edit the Drush alias to point to your Drush 8 script

I can open a separate PR for that if you'd like, though we might want to smooth out the approach first.

I'm sure there will be much massaging here, but hopefully this gets us started!

[arh1]

Per our chat today, yes we want to avoid that hackery for Drush 8 :) and use the SSHKit command map instead.

I was able to drop my third bullet above and change the second to just adding these lines:

  SSHKit.config.command_map[:drush] = "../vendor/drush/drush/drush"
  puts SSHKit.config.command_map[:drush]

Immediately under:

namespace :drush do

in lib/capistrano/tasks/drush.rake .

Note that the path could change to ../vendor/bin/drush if I get symlinks working during the deployment rsync. Also, I'm not sure yet if this relative path will work for everything we do with Drush. I haven't been able to get a full path working yet with something like:

  SSHKit.config.command_map[:drush] = "#{release_path}/#{fetch(:app_webroot, 'public')}/../vendor/drush/drush/drush"

[arh1]

@generalconsensus and @chazchumley just a ping on this in that I know you're both actively working on D8 stuff.

No action needed, but just thought you might be curious. (Even though I opened the PR, still a work in progress on my end as I'm encountering new issues. :/ )

[generalconsensus]

@arh1 @fafnirical What is a best practice for updating the site with composer? Say I wanted to patch a d8 site with the latest sec bug, should we add a line to the drupal8.rb file to allow for composer to update drupal on deploy?

Bad idea/good idea?

[fafnirical]

@generalconsensus Our overall workflow for Drupal updates hasn't changed much with Composer vs. the drush workflow. On your local machine (inside or outside VM), you'd just run composer update and push:

git checkout feature-branch
# This should update composer.lock and <web-root>/core.
composer update drupal/core --with-dependencies
# Optional:
# git push origin feature-branch
git checkout master
git merge --no-ff feature-branch
git push origin master

[wwhurley]

Generally speaking dependencies should be handled during the build and not during the deployment. So issues with Composer should be handled in Jenkins and not by Capistrano.

[generalconsensus]

@arh1 Just wanted to mention that we've had problems with configuration. I yanked out the configuration import work and the rest worked

[arh1]

Note that the path could change to ../vendor/bin/drush if I get symlinks working during the deployment rsync.

fwiw, note that if we're happy w/ the change in #275 we could now change those paths in lib/capistrano/tasks/drush.rake .