Adding Drupal VM 3.1 integration.

[grasmash]

No description provided.

[grasmash]

Need to wait for Drupal VM 3.1.0. Will update version in composer.json, update docs.

[oxyc]

This is no longer required, Drupal VM added it as a hard dependency geerlingguy/drupal-vm#551.

[grasmash]

I suspect these mysql settings may cause a problem. Perhaps if this user already exists with a password. @geerlingguy would you happen to know?

[geerlingguy]

Drupal VM 3.1.0 was tagged and released today: https://github.com/geerlingguy/drupal-vm/releases/tag/3.1.0

The release includes Solr 5.x as a default, and you can now just write variables you want to override to config.yml (and then developers can override with a gitignored local.config.yml file). No need to copy the entire default.config.yml anymore.

Finally, Drupal VM itself now builds Composer projects and/or composer.json files (this should be disabled for BLT projects, since it's handled by BLT itself via Phing, of course).

I'm going to see if some of the Composer performance optimizations help any with BLT-generated projects, too. I hate idling while waiting for composer update :P

[CashWilliams]

small and picky of me, but why hard code to .local?

[CashWilliams]

make sense to use ${project.local_uri} instead?

[geerlingguy]

That's often an annoyingly long string, though... it's not a huge deal to me either way, but I like [machinename].local as a convention, and then developers can technically override their local site URLs and use whatever they'd like.

Some devs like "mysitename.local", others "www.mysitename.dev", others "local.mysitename.com", etc.

Having this particular string separate from the URI gives devs a lot more flexibility, imo.

[geerlingguy]

(Plus it follows the convention for the other environments, of [machine].local, .dev, .prod, etc.)

[grasmash]

Aaaand local_uri doesn't actually exist. Gotta add that.

[CashWilliams]

For some reason I feel like this should be ${project.machine_name}.vm rather then .localhost

[geerlingguy]

It really should be ${project.local_uri}—see https://github.com/acquia/blt/pull/113/files#diff-1d79176dc01e3cdc73b4066200be0e02R2

[grasmash]

true.

[geerlingguy]

Note that the default Drupal VM config installs Ubuntu 16.04 and PHP 7.0.x, and this seems to make Lightning's drush site-install task fail:

project > setup:drupal:install:

    [drush] Executing '/Users/jeff.geerling/Sites/acquia/blted8/vendor/bin/drush @self --site-name="BLTed 8" --site-mail="no-reply@acquia.com" --account-name="admin" --account-pass="admin" --account-mail="no-reply@acquia.com" --l="default" --nocolor --yes --verbose site-install "lightning" "install_configure_form.update_status_module='array(FALSE,FALSE)'"'...
Loaded alias @self from file                                                                                    [notice]
/Users/jeff.geerling/Sites/acquia/blted8/drush/site-aliases/drupal-vm.aliases.drushrc.php
Begin redispatch via drush_invoke_process().                                                                    [notice]
Calling proc_open(ssh -o PasswordAuthentication=no -i /Users/jeff.geerling/.vagrant.d/insecure_private_key vagrant@local.testblt.com 'env COLUMNS=120 drush  --local --alias-path=/Users/jeff.geerling/Sites/acquia/blted8/drush/site-aliases --nocolor --yes --verbose --uri=default --root=/var/www/blted8/docroot  site-install lightning '\''install_configure_form.update_status_module='\''\'\'''\''array(FALSE,FALSE)'\''\'\'''\'''\''   --site-name='\''BLTed 8'\'' --site-mail='\''no-reply@acquia.com'\'' --account-name=admin --account-pass=admin --account-mail='\''no-reply@acquia.com'\'' 2>&1' 2>&1);
End redispatch via drush_invoke_process().                                                                      [notice]
    [drush] Warning: Permanently added the ECDSA host key for IP address '192.168.88.88' to the list of known hosts.
    [drush] Loaded alias @self from file /var/www/blted8/docroot/../drush/site-aliases/drupal-vm.aliases.drushrc.php        [notice]
    [drush] Executing: mysql --defaults-extra-file=/tmp/drush_U2aJQU --database=drupal --host=localhost --port=3306 --silent  < /tmp/drush_cem0wJ > /dev/null
    [drush] You are about to create a /settings.php file and create a sites/sites.php file and DROP all tables in your 'drupal' database. Do you want to continue? (y/n): y
    [drush] bash: line 1:  7470 Segmentation fault      env COLUMNS=120 drush --local --alias-path=/Users/jeff.geerling/Sites/acquia/blted8/drush/site-aliases --nocolor --yes --verbose --uri=default --root=/var/www/blted8/docroot site-install lightning 'install_configure_form.update_status_module='\''array(FALSE,FALSE)'\''' --site-name='BLTed 8' --site-mail='no-reply@acquia.com' --account-name=admin --account-pass=admin --account-mail='no-reply@acquia.com' 2>&1
[phingcall] /Users/jeff.geerling/Sites/acquia/blted8/build/core/phing/tasks/setup.xml:73:85: Drush exited with code 139

BUILD FAILED
/Users/jeff.geerling/Sites/acquia/blted8/build/core/phing/tasks/local-sync.xml:12:30: Execution of the target buildfile failed. Aborting.

Total time: 49.0135 seconds

Debugging further, it seems the site installation works fine via Drupal's UI installer (though there are a bunch of entity errors on first page load after install in Lightning), and site installation also works fine using standard or minimal as the install profile with vanilla Drupal VM's install_site option. I haven't tested out using blt.sh with those options yet.

[CashWilliams]

I think the way DrupalVM is pulled in to vendor here makes it such that the VagrantFile (inside DrupalVM) isn't finding a VagrantFile.local override. @geerlingguy would need to confirm though.

[oxyc]

@CashWilliams it looks for it in box/Vagrantfile.local.

[CashWilliams]

@oxyc thanks, that kind makes sense, I'll test it out.

[CashWilliams]

With the latest commits, this is now building and installing for me. 👍

However there is still an issue with drush aliases:

• Multiple versions are created everywhere. DrupalVM creates some, blt creates some, and there seems to be a few more laying around.
• The best alias I can see to use only works from Host->VM. Logging into the VM, the alias does not work b/c it is trying to reference a remote.

[dpagini]

Can I ask a quick question on this PR, @grasmash? Is the intent that the individual setting up the repo would run this vm:init command once, and then commit the Vagrantfile (and others)? Or would each individual developer that wants to use Drupal VM run the vm:init command?
I only ask b/c I'm wondering if we need more in the .gitignore file? Such as a "box" folder? Or would the intent be that the box folder gets committed to the repo?

[grasmash]

The intent is that after generating a project, someone would run vm:init once and then commit the generated files. I suppose that should be documented.