Include roles with Drupal VM codebase

[geerlingguy]

So... I was thinking on a long drive how annoying it is for anyone who's not a 'power user' and knows the hack to prevent reinstalling all roles on every provision to have to download every role on every provision.

Also, I keep seeing issues like #813 crop up in the issue queue.

And since ansible/galaxy-issues#165 is at best in pretty preliminary stages, I don't think Galaxy itself or Vagrant's requirements file integration will be up to handling initial role download/future updates with idempotence anytime too soon.

So rather than all that, we can 'compile in' all the roles, by adding the roles to the Drupal VM repo.

In all, the roles are ~2MB, and compressed as part of the project's archive, they'd be much less.

The tradeoffs:

• Any time a role is updated in requirements, the contributor also needs to re-run ansible-galaxy install and commit the changed/updated role files, which is a manual pre-commit process... but we could figure out a way to automate it better.
• All the role changes will be tracked in the Drupal VM repo, which clutters up history a little (not a huge deal, and many/most Drupal site codebases are managed similarly...).
• The Drupal VM zip download or full git clone will more than double in size (not that we're talking anything giant to begin with... still < 3 MB :)
• My role's numbers for Ansible Galaxy downloads won't keep inflating at the insane rate they currently do (since there will be thousands fewer downloads per month). Too bad for my ego ;)

The benefits:

• Save 1-5 minutes of time on every up and provision, for everyone.
• Prevent errors when Galaxy's API goes away (I currently see a new GitHub issue related to this problem every week or so...).
• Drupal VM is more of a 'complete package' and people get up and running more quickly/portably.

TODO

• Remove the roles dir from .gitignore
• Commit the roles to the repo.
• Add an ansible.cfg file with the roles_path defined inside the provisioning directory.
• Remove the galaxy file config from the Vagrantfile (so Vagrant doesn't manage the roles).
• Update the docs and remove the mention of the local Vagrantfile hack that's no longer necessary.
• Maybe add a README.md inside the provisioning directory or inside the roles directory that tells people to contribute changes to the roles themselves in the upstream role repositories, and also gives directions for updating the roles via an updated requirements.yml file.
• Remove galaxy install step from Travis config.
• Test on Mac with and without Ansible installed. Test on Windows.
• Update windows.sh to not use the galaxy requirements file? (This will technically fork the windows.sh file from the upstream JJG-Ansible-Windows project... :/

This will basically be like a 'poor man's lockfile' approach. It'll be a grand experiment!

[geerlingguy]

Alrighty, going to PRify things and see how the tests go on Travis too.

[thom8]

Interesting idea - could git sub modules work here as you don't need to track role changes in this project and updating a role would be just updating the submodule ref?

You'd just need to clone with the --recursive option.

[geerlingguy]

@thom8 - I'd rather not do submodules as it always causes some unforeseen weird issue in some scenario or another; however, if it seems this method is not as ideal as I'm thinking it will be, we can move down another path. I still like the simplicity of using a Galaxy requirements file (vs. submodules/esoteric git usage).

[thom8]

@geerlingguy no worries - they would also make it easier to contribute to the upstream roles from within DVM as you can just run git remote set-url origin [git URL of fork] inside the role to start pushing commits to your fork to create PRs.

There's also a small risk that a PR could potentially fork a DVM role from the main role, but since you're the maintainer of both this shouldn't be a problem :)

Maybe git sub trees could help just to keep the roles updated and syncd both ways.