Invoke blt frontend from inside drupalVM

[aweingarten]

When DrupalVM is configured for a BLT repo, and a user executes blt frontend from outside the VM please ssh into the vm and execute blt frontend from inside the VM. This will ensure consistent experience for front-end build tools, and remove local install problems.

[geerlingguy]

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).

[geerlingguy]

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:

1. Create a new passwordless SSH key (either in the VM with ssh-keygen, or in Windows) just for project use.
2. Make sure the key is in the VM at /home/vagrant/.ssh/id_rsa
3. Add the public key to their GitHub account.
4. Add the public key to their Acquia Cloud account.

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).

[geerlingguy]

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.

#dumbTerminal for the win — I know a couple customers who had really weak and locked down laptops, where even Drupal VM was a step too far. They could use cheap AWS instances for dev (or any kind of Cloud instance), just like they would Drupal VM (and Drupal VM could be configured to provision those instances as well).

[geerlingguy]

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

[aweingarten]

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!

[geerlingguy]

Interesting... that seems like it could work.

[geerlingguy]

$ 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?

[aweingarten]

--no proxy is an idea I came up with that we could use in the blt command to tell it to not proxy

[aweingarten]

@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