Add a development option

[andydempster]

Issue Type

• Feature Idea

Your Environment

Vagrant 1.9.1
VirtualBox 5.1.12r112440
ansible 2.2.0.0

Your OS

• Ubuntu 14.04 LTS

Summary

Whilst installing the VM this morning for a community contrib sprint I had to replace the Drupal version with the latest dev release for patch testing. I was wondering what the process would be to add a development: true/false option in the default.config.yml that would then use git to clone the drupal repository and finally run composer install/update thereby ensuring the latest dev version is present?

(related to https://github.com/geerlingguy/drupal-vm/issues/1044)

[oxyc]

First few comments and commtis are partly related https://github.com/geerlingguy/drupal-vm/issues/618

I don't think there's any way to support this feature without bundling multiple composer/make files. Probably not even possible for the default drupal-project setup.

[geerlingguy]

@BrizzleRocker - Yeah, a long time ago, we used to default to the 8.x-dev release of core via git checkout, using a Drush make file. You can still get at it if you customize the makefile and build that way. You can also use a customized drupal.composer.json file that grabs the dev release if you'd like, but for my purposes, I usually maintain a clone of the drupal repo locally, and share it into a Drupal VM instance as needed when I want to do some core development/testing.

[oxyc]

I think you also can do something like:

DRUPALVM_ANSIBLE_ARGS='--extra-vars=@~/.drupalvm/dev.drupal.yml' vagrant provision

$ cat ~/.drupalvm/dev.drupal.yml

build_composer_project: false
build_composer: true
drupal_composer_path: "~/.drupalvm/dev.composer.json"

And ansible will load that yaml file. Our Vagrantfile doesnt load this though, so you cant add stuff such as synced folders.

http://docs.ansible.com/ansible/playbooks_variables.html#passing-variables-on-the-command-line

[andydempster]

I assume I can just use local.config.yml to share a Drupal dev folder as @geerlingguy said?

[wturrell]

Could we add a paragraph in the docs, along the lines of "this is how to setup DrupalVM for contributing to core"?

[andydempster]

@wturrell that would be awesome. It would certainly be a great help for the contrib community!

[thom8]

@BrizzleRocker you could also try https://github.com/thom8/drupal8-vagrant which implements a preprovisioned version of DrupalVM and specifically built for Drupal code sprints.

[geerlingguy]

Yeah, that too-the above VM is highly optimized just for sprint purposes (and is helpful outside that context too).

For my purposes, I'm working anywhere between 20-40 core patches at a time for various projects, so I have one 8.x core checkout on my local machine, with a branch for each patch, and I can work through there. I sync that directory into Drupal VM as needed for testing.

[wturrell]

@geerlingguy quick question - how do you deal with switching (for example) between 8.3.x and 8.4.x? It sounds like you're doing it all on a single VM? I've now moved my core dev over to Drupal VM from Acquia DevDesktop (latter is fastest way to spin up new sites, but too many problems: 2038 time bug due to it running in 32-bit, no xDebug, certain tests not passing when run in MacOS etc.) But not sure of a good way to handle different database and configuration states between branches, e.g. whether I need two separate VMs as I used to do with DevDesktop, or perhaps I should trash the DB and use drush to cleanly install a new one when switching between branches?

[geerlingguy]

@wturrell - I generally use one VM for all 'misc dev' stuff, and switch things around with git and Drush alone. Otherwise, I have a VM per project, just so I can vagrant up an instance that's specific to that project (for long-term sites).

[geerlingguy]

I'm going to close out this issue for now, and point people towards using https://github.com/thom8/drupal8-vagrant, which is more purpose-built to Drupal Core/Contrib work and sprinting.

For someone more comfortable doing everything in a local clone of Drupal and Contrib modules, it doesn't matter what method you use, but for those who would like the guidance, Thom's project is going to get you from start to sprinting more quickly than Drupal VM :)

[cdubz]

Is this topic relevant again? I was pursuing the same thing recently -- getting a quick and reusable environment together for core contrib -- and had trouble using drupal-vm for this efficiently (despite the easy setup). https://github.com/thom8/drupal8-vagrant appears to be abandoned at this point.