Closed aweingarten closed 7 years ago
Most Windows devs seem to do this, and it makes the consistency of local builds a little better, as you can guarantee all devs will have the exact same Node.js version installed, and gulp can be installed globally in the VM.
For one project where we have a mix of Mac and Windows-based developers, we added the following configuration to power asset compilation for Sass/KSS for Cog (also works with Bootstrap):
nodejs_version: "4.x"
nodejs_npm_global_packages:
- name: gulp
nodejs_install_npm_user: "{{ drupalvm_user }}"
npm_config_prefix: "/home/{{ drupalvm_user }}/.npm-global"
installed_extras:
...
- nodejs
...
Otherwise, each developer has to manually install Node.js... or nvm
, or avn
, or run the install_node.sh
script in the Cog theme directory, and also make sure to install yarn
and gulp
, and it can start getting a little dizzying having to install multiple node versions, multiple package managers, and other software—not to mention getting the right version (if you have version mismatches, and build the theme with Node 4.x, then again with 6.x, you'll likely run into funny errors with node-sass
and have to delete your node_modules
folder entirely).
The biggest problem with some commands (e.g. local:refresh
, which retrieves a DB via SSH from Acquia Cloud), is that they require a valid SSH key to work, so the hardest part with most new developers is helping them understand how to use SSH keys in their local environment.
Right now, for windows devs, I recommend they:
ssh-keygen
, or in Windows) just for project use./home/vagrant/.ssh/id_rsa
On the Mac or Linux, if you use ssh-add
(SSH Agent), Drupal VM automatically works with your added SSH keys in your home folder. On Windows, devs currently have to manually set up their key (or just create a new key anytime they rebuild their VM).
It looks like the path forward would be to modify https://github.com/acquia/blt/blob/8.x/bin/blt to allow for execution in the current environment or via SSH.
One interesting side effect... if we made the SSH connection configurable—then BLT could also be used to deploy and manage things outside of just the local environment. If devs used cloud environments (to which they had SSH access), they could execute commands remotely inside that environment as well.
Also note some things about usage inside a Windows 10 environment (in addition to all the other notes): https://www.jeffgeerling.com/blog/2017/set-blt-and-drupal-vm-entirely-within-windows-10
Been doing some light research on this topic. Thinking we might be able to use drush ssh
as an abstraction layer here:
drush help ssh
Connect to a Drupal site's server via SSH for an interactive session or to run a shell command
Examples:
drush @mysite ssh Open an interactive shell on @mysite's server.
drush @prod ssh ls /tmp Run "ls /tmp" on @prod site. If @prod is a site list, then ls will be executed on each site.
drush @prod ssh git pull Run "git pull" on the Drupal root directory on the @prod site.
Arguments:
bash Bash to execute on target. Optional, except when site-alias is a list.
Options:
--cd Directory to change to. Use a full path, TRUE for the site's Drupal root directory, or --no-cd for the ssh default
(usually the remote user's home directory). Defaults to the Drupal root.
--escaped Command string already escaped; do not add additional quoting.
--ssh-options A string of extra options that will be passed to the ssh command (e.g. "-p 100")
--tty Create a tty (e.g. to run an interactive program).
Topics:
docs-aliases Site aliases overview on creating your own aliases for commonly used Drupal sites with examples from
example.aliases.drushrc.php.
docs-strict-options Strict option handling, and how commands that use it differ from regular Drush commands.
Aliases: ssh
the primary blt command can simply proxy all it's calls to drush ssh blt -no-proxy <whatever you actually intended to run> --no-proxy
can be used to ensure that blt doesn't enter an infinite drush ssh loop!
Interesting... that seems like it could work.
$ drush @project.local ssh blt version
blt > version:
[echo] BLT version is 8.6.15
BUILD FINISHED; 3.1718 seconds
That worked (even passed through colors correctly!), but I couldn't do anything with --no-proxy
—I don't see where that comes from?
--no proxy is an idea I came up with that we could use in the blt command to tell it to not proxy
@geerlingguy, @grasmash Messing around I came up with something that is close. This works locally. I was able to seamlessly kick-off a node front-end build inside a DrupalVM. That being said I've hard-coded the drush alias which clearly won't work. Need to come up with a solution to get that.
/bin/blt
#!/usr/bin/env bash
if [ "`git rev-parse --show-cdup 2> /dev/null`" != "" ]; then
GIT_ROOT=$(git rev-parse --show-cdup)
else
GIT_ROOT="."
fi
if [ -f "$GIT_ROOT/vendor/acquia/blt/bin/blt" ]; then
drush @capitalcamp.local ssh cd .. & ./vendor/bin/phing -f "./vendor/acquia/blt/phing/build.xml" -logger vendor.acquia.blt.phing.phingcludes.BltLogger "$@"
else
echo "Error: You must run this command from within a BLT-generated project repository!"
fi
When DrupalVM is configured for a BLT repo, and a user executes
blt frontend
from outside the VM please ssh into the vm and executeblt frontend
from inside the VM. This will ensure consistent experience for front-end build tools, and remove local install problems.