I’m using trellis/bedrock/sage 9 beta. Sage 9 includes a yarn installation that needs to be run from the dev box, not the vagrant vm. Right now our process for getting a dev set up on the repo is ‘vagrant up’ followed by navigating to the /sage9/ theme directory to run ‘yarn’ and ‘yarn run build’ to pull in the JS deps for yarn.
What I’d like to do is update the trellis ansible playbooks to run these commands from the local machine, so getting started is as simple as ‘vagrant up’ and you’re done.
The missing pieces are:
How do I make a play run from the context of the host machine? I’ve tried a few connection: local and hosts attempts to no avail.
How do I reference the host project root path? It it possible to access the ENV or other variables set in Vagrantfile from within a playbook?
I imagine a dev would need to run yarn and yarn run build commands a number of times over the course of developing a project, so my initial reaction was that automating the single first run of these commands may not be worth the hassle and may even hinder a newer dev’s understanding of the distinction between tools and how they work together.
Or perhaps your devs don’t do any of the initial setup anyway, so you’re trying to automate it completely to save yourself time.
Whatever the case may be, here are some thoughts on how to automate the commands.
Ansible on host. Could you install Ansible on the host machine? Trellis will run the host’s version of Ansible, if it is installed. But note that Ansible cannot yet use Windows as the host machine.
(Untested) If Ansible is installed on the host machine, you could then follow the examples in deploy-hooks/build-before.yml (but drop the Copy production assets task).
However, note that those examples are for a slightly different context, so they would need some modifications.
The examples run in the context of a single site from wordpress_sites. If you’re running this for local dev, you probably need the commands to run for all sites in wordpress_sites, so you’d want to add to each task a with_dict: "{{ wordpress_sites }}" parameter (to loop over hash).
In the chdir parameter of each task, you could then use item.value.local_path as a var to the host’s path to the site directory (bedrock-based project).
Also note that the example tasks are associated with deploy.yml which does not invoke sudo like dev.yml does (via become parameter). If you are adding such tasks to the dev.yml context, you will probably need to add to each task a become: no to prevent the tasks from running as root on the host machine (see local-connection example from Trellis).
vagrant-triggers plugin. Alternatively, you could try the vagrant-triggers plugin made for automatically running commands on the host when certain vagrant commands are run. Note the plugin’s maintenance status. I think I’ve heard some question about the plugin’s compatibility with recent versions of Vagrant.
project-init.sh script. I suspect you would want to run yarn and yarn run build only on the very first vagrant up, and perhaps not on future occurrences of vagrant up or vagrant provision for the specific project. In that case, you may consider creating a simple project-init.sh script with your desired vagrant up and other commands.
Perhaps this wrapper script approach would have the fewest complications and afford you the most flexibility now and in future.
Gotta agree with fullyint here. Unless you have developers who are only coding PHP and doing back-end work, then they’ll be running npm or yarn to watch CSS and JS to rebuild. An initial yarn could be helpful I suppose, but each dev should understand how the tools work and be able to get it working.
We do have some folks who don’t need to do theme dev but nonetheless need to install the app locally. That said, fullyint is right and it isn’t worth the hassle to set this up to save on a command or two.