Demo Setup instructions fail with composer error

[jmdfm]

• I've read the guidelines for Contributing to Roots Projects
• This is a bug report for the roots-example-project.com repo and not for Trellis, Bedrock, Sage or Soil
• I've read the docs for Trellis, Bedrock, Sage and Soil (if applicable) and followed them
• This is not a personal support request that should be posted on the Roots Discourse forums

What is the current behavior?

The demo installation instructions fail with an error message on the TASK [wordpress-install : Install Dependencies with Composer] step:

failed: [default] (item={'value': {u'multisite': {u'enabled': False}, u'cache': {u'enabled': False}, u'ssl': {u'enabled': True, u'provider': u'self-signed'}, u'local_path': u'../site', u'site_hosts': [u'roots-example-project.dev'], u'admin_email': u'admin@roots-example-project.dev'}, 'key': u'roots-example-project.com'}) => {"changed": true, "cmd": ["composer", "install"], "delta": "0:00:00.085437", "end": "2016-06-16 18:42:44.447055", "failed": true, "item": {"key": "roots-example-project.com", "value": {"admin_email": "admin@roots-example-project.dev", "cache": {"enabled": false}, "local_path": "../site", "multisite": {"enabled": false}, "site_hosts": ["roots-example-project.dev"], "ssl": {"enabled": true, "provider": "self-signed"}}}, "rc": 1, "start": "2016-06-16 18:42:44.361618", "stderr": "You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug\nRunning composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted\nComposer could not find a composer.json file in /srv/www/roots-example-project.com/current\nTo initialize a project, please create a composer.json file as described in the https://getcomposer.org/ \"Getting Started\" section", "stdout": "", "stdout_lines": [], "warnings": []}

Destroying the vagrant image and retrying consistently produces the same error.

What is the expected or desired behavior?

The demo instructions should work, and I should be able to view the example project.

---

Bug report

Please provide steps to reproduce, including full log output:

Follow the instructions in the README of this repo exactly as laid out.

Please describe your local environment:

Ansible version: 2.1.0.0
OS: 10.11.5
Vagrant version: 1.8.4

Where did the bug happen? Development or remote servers?

Development server setup

Please provide a repository or your wordpress_sites config (if possible):

N/A

Is there a related Discourse thread or were any utilized (please link them)?

There is a Discourse thread that seems related https://discourse.roots.io/t/stderr-composer-could-not-find-a-composer-json-file-in-var-www-localhost-current/4698/8

[swalkinshaw]

I don't know if this is the only problem but you're using an incompatible version of Ansible. 2.0.2.0 is required as per the Trellis README.

Closing until you fix that and see if everything works.

More info: https://discourse.roots.io/t/taskinclude-object-has-no-attribute-has-triggered/6834/14?u=swalkinshaw

[jmdfm]

Wow, do you think you could maybe take the time to read and investigate the issue before closing it?

This is clearly not an Ansible error. You have a bunch of people reporting the same issue on Discourse.

And yes, surprise surprise, downgrading Ansible to 2.0.2, destroying the Vagrant image and rebuilding produces the exact same error.

Can you try the simple step of reproing your own setup instructions in the README and see if you get the same error, because I'm certain you will...

[jmdfm]

Just had a colleague who didn't have any of the dependencies or any previous versions of the project try your Development environment setup instructions and they ended up with the same missing composer file error.

Something is either missing in the instructions or they are now out of date.

[paultibbetts]

I can confirm the following worked for me:

$ history
  411  cd sites
  412  mkdir tmp
  414  cd tmp
  415  git clone git@github.com:roots/roots-example-project.com.git
  416  cd roots-example-project.com/trellis
  417  ansible-galaxy install -r requirements.yml
  418  cd ../site/web/app/themes/sage
  419  nvm use 5.10.0
  420  npm install && bower install && gulp
  421  cd ../../../
  422  ls
  423  cd ../../trellis
  424  vagrant up

Vagrant 1.8.1
Ansible 2.0.2.0
OSX 10.11.5
Composer 1.1.2

@johnmcdowall are you following the instructions or the part on local development setup?

If the local development setup isn't working for you I'd recommend following the "here's how this repository was made" instructions and configuring each of the projects individually according to the requirements in their own readme.

This is clearly not an Ansible error.

There have been problems with Ansible versions higher than 2.0.2 getting stuck on certain tasks.

You have a bunch of people reporting the same issue on Discourse

Could you help us debug the issue please?

Can you go to the Trellis folder of the example project, run vagrant ssh to login to the VM, and run ls -la /srv/www/roots-example-project.com/current so that we can see what's inside your current folder?

It should look like the following:

$ vagrant@roots-example-project:/srv/www/roots-example-project.com/current$ ls -la
total 88
drwxr-xr-x 18 vagrant www-data   612 Jun 17 11:26 .
drwxr-xr-x  5 vagrant www-data  4096 Jun 17 11:26 ..
-rw-r--r--  1 vagrant www-data   192 Jun 17 11:08 .editorconfig
-rw-r--r--  1 vagrant www-data   239 Jun 17 11:26 .env
-rw-r--r--  1 vagrant www-data   471 Jun 17 11:08 .env.example
-rw-r--r--  1 vagrant www-data   356 Jun 17 11:08 .gitignore
-rw-r--r--  1 vagrant www-data   375 Jun 17 11:08 .travis.yml
-rw-r--r--  1 vagrant www-data  3461 Jun 17 11:08 CHANGELOG.md
-rw-r--r--  1 vagrant www-data   110 Jun 17 11:08 CONTRIBUTING.md
-rw-r--r--  1 vagrant www-data  1044 Jun 17 11:08 LICENSE.md
-rw-r--r--  1 vagrant www-data  3414 Jun 17 11:08 README.md
-rw-r--r--  1 vagrant www-data  1505 Jun 17 11:08 composer.json
-rw-r--r--  1 vagrant www-data 17033 Jun 17 11:08 composer.lock
drwxr-xr-x  4 vagrant www-data   136 Jun 17 11:08 config
-rw-r--r--  1 vagrant www-data   284 Jun 17 11:08 phpcs.xml
drwxr-xr-x 11 vagrant www-data   374 Jun 17 11:26 vendor
drwxr-xr-x  6 vagrant www-data   204 Jun 17 11:26 web
-rw-r--r--  1 vagrant www-data    13 Jun 17 11:08 wp-cli.yml

[MogwaiMomo]

Hi there @ptibbetts, I've been having the same problem as @johnmcdowall ; revived a related thread on Discourse whose title was the same error message but @swalkinshaw closed it:

https://discourse.roots.io/t/stderr-composer-could-not-find-a-composer-json-file-in-var-www-localhost-current/4698

I get that the original Discourse poster had a specific context to his/her problem and happened to fix it somehow by destroying & re-provisioning, but the error message and root issue seems to persist for other people, so it would be awesome if we can get to the bottom of this without just closing it and moving on. (As yet I haven't seen anyone actually post a conclusive reason why this keeps happening.)

@ptibbetts I followed your specific setup as well but ended up with the same missing composer.json issue. The current folder in the vm instance ends up empty, as shown:

This actually has come up in another issue as shown here:
roots/trellis#128
but no conclusive fix was described beyond checking for problems with the vagrant sync folder (and then @swalkinshaw locked it). As I'm trying to set up the roots-example-project and have not touched any of its code before trying to set it up, I'm not sure what's going on here. Still trying to figure it out.

[swalkinshaw]

@MogwaiMomo all I said was that wasn't the thread to continue the issue in. You're free to make another one for your specific issue and provide us with details so we can help you. You still haven't posted your setup with versions either.

[MogwaiMomo]

Hi @swalkinshaw re: Discourse thread - sure, and I apologize if I sound testy but I've been chasing this issue for a while now and every thread I find is either locked or closed without a clear resolution (including this one :P )

In any case, any & all help is v. much appreciated ... without further ado, my current setup with versions is:

Ansible 2.0.2.0
VirtualBox 5.0.20
Vagrant 1.8.4
vagrant-bindfs (0.4.7)
vagrant-hostmanager (1.8.1)
OSX 10.10.5
Composer 1.1.2

Here's a screenshot of the commands I ran (same as @ptibbetts):

And (if it helps) here's the full error message:

TASK [wordpress-install : Install Dependencies with Composer] ******************
failed: [default](item={'value': {u'multisite': {u'enabled': False}, u'cache': {u'enabled': False}, u'ssl': {u'enabled': True, u'provider': u'self-signed'}, u'local_path': u'../site', u'site_hosts': [u'roots-example-project.dev'], u'admin_email': u'admin@roots-example-project.dev'}, 'key': u'roots-example-project.com'}) => {"changed": true, "cmd": ["composer", "install"], "delta": "0:00:00.147648", "end": "2016-06-18 21:46:00.600068", "failed": true, "item": {"key": "roots-example-project.com", "value": {"admin_email": "admin@roots-example-project.dev", "cache": {"enabled": false}, "local_path": "../site", "multisite": {"enabled": false}, "site_hosts": ["roots-example-project.dev"], "ssl": {"enabled": true, "provider": "self-signed"}}}, "rc": 1, "start": "2016-06-18 21:46:00.452420", "stderr": "You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug\nRunning composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted\nComposer could not find a composer.json file in /srv/www/roots-example-project.com/current\nTo initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section", "stdout": "", "stdout_lines": [], "warnings": []}

Again, apologies if my frustration leaked into my typing ... any tips/ideas are very much appreciated. Would love to get this sorted.

[fullyint]

The git clone git@github.com:roots/roots-example-project.com.git approach works for me.
I'm unable to reproduce the issue.

OSX 10.11.5
Ansible 2.0.2.0
VirtualBox 5.0.20
Vagrant 1.8.4

$ vagrant plugin list
  vagrant-bindfs (0.4.7)
  vagrant-hostmanager (1.8.1)
  vagrant-share (1.1.5, system)

---

If I understand correctly, @johnmcdowall and @MogwaiMomo, your host machine does indeed have the composer.json etc. in some/path/roots-example-project.com/site (i.e., the git clone worked completely) but the files aren't successfully synced to the guest vm at /srv/www/roots-example-project.com/current.

When things work correctly, the site directory (with composer.json) is synced in two steps.

• First - From your host machine to vm guest at /vagrant-nfs-roots-example-project.com. Then...
• Second - From the above location to the expected /srv/www/roots-example-project.com/current

Apparently one of the above sync steps is failing.

One approach to start debugging a sync problem could be to examine Vagrant output regarding these shared/synced folders. Following your vagrant up there is output such as this:

==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
Password:
==> default: Mounting NFS shared folders...
==> default: Mounting shared folders...
    default: /vagrant => /Users/philip/projects/roots/roots-example-project.com/trellis
==> default: Bindfs seems to not be installed on the virtual machine, installing now
==> default: Creating bind mounts for selected devices
==> default: Creating bind mount from /vagrant-nfs-roots-example-project.com to /srv/www/roots-example-project.com/current

This default output (above) doesn't show the "First" of the two sync steps I listed above, but you can get more detailed output by adding the --debug option.

Destroy your vagrant vm and run vagrant up --debug. Once it appears the vagrant vm is done starting up and done syncing folders, you can just cancel the operation, e.g., once the Ansible playbook has started and you see lines such as these:

==> default: Running provisioner: ansible...
    default: Running ansible-playbook...
PLAY [WordPress Server: Install LEMP Stack with PHP 7.0 and MariaDB MySQL] *****

Before you go to the effort of searching through the super long debug output, you might just do a quick vagrant ssh and ls -al /srv/www/roots-example-project.com/current to see if the composer.json et al. aren't there this time around. You might as well also run ls -al /vagrant-nfs-roots-example-project.com just to check whether the problem was with the First or Second sync step.

If the files are not there, you could search your long vagrant --debug output for lines/snippets such as these below, comparing your output with the snippets below from a successful sync setup.

==> default: Exporting NFS shared folders...
DEBUG host: Searching for cap: nfs_export
DEBUG host: Checking in: darwin
DEBUG host: Checking in: bsd
DEBUG host: Found cap: nfs_export in bsd
 INFO host: Execute capability: nfs_export [#<Vagrant::Environment: /Users/philip/projects/roots/roots-example-project.com/trellis>, #<Vagrant::UI::Prefixed:0x00000101e7d450 @logger=#<Log4r::Logger:0x00000101e7d400 @fullname="vagrant::ui::interface", @outputters=[], @additive=true, @name="interface", @path="vagrant::ui", @parent=#<Log4r::Logger:0x00000100b214d8 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x000001018efc90 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x000001018ef9c0>, @name="stderr", @level=0, @formatter=#<Log4r::DefaultFormatter:0x00000101be5530 @depth=7>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x00000100b213c0 @level=0, @outputters=[]>, @level=1, @trace=false>, @level=1, @trace=false>, @opts={}, @stdin=#<IO:<STDIN>>, @stdout=#<IO:<STDOUT>>, @stderr=#<IO:<STDERR>>, @prefix=:default, @ui=#<Vagrant::UI::Colored:0x00000101c0fa88 @logger=#<Log4r::Logger:0x00000101c0fa38 @fullname="vagrant::ui::interface", @outputters=[], @additive=true, @name="interface", @path="vagrant::ui", @parent=#<Log4r::Logger:0x00000100b214d8 @fullname="vagrant", @outputters=[#<Log4r::StderrOutputter:0x000001018efc90 @mon_owner=nil, @mon_count=0, @mon_mutex=#<Mutex:0x000001018ef9c0>, @name="stderr", @level=0, @formatter=#<Log4r::DefaultFormatter:0x00000101be5530 @depth=7>, @out=#<IO:<STDERR>>>], @additive=true, @name="vagrant", @path="", @parent=#<Log4r::RootLogger:0x00000100b213c0 @level=0, @outputters=[]>, @level=1, @trace=false>, @level=1, @trace=false>, @opts={:color=>:default}, @stdin=#<IO:<STDIN>>, @stdout=#<IO:<STDOUT>>, @stderr=#<IO:<STDERR>>, @lock=#<Mutex:0x00000101bd5720>>>, "9ddb142d-6f3f-4974-9a7f-94a5feba5c66", ["192.168.50.5"], {"/vagrant-nfs-roots-example-project.com"=>{:type=>:nfs, :guestpath=>"/vagrant-nfs-roots-example-project.com", :hostpath=>"/Users/philip/projects/roots/roots-example-project.com/site", :disabled=>false, :__vagrantfile=>true, :map_uid=>501, :map_gid=>0, :nfs_udp=>true, :nfs_version=>3, :uuid=>"1111244617"}}] (darwin)
...
DEBUG bsd: Compiling map of sub-directories for NFS exports...
 INFO bsd: Exporting the following for NFS...
 INFO bsd: NFS DIR: ["/Users/philip/projects/roots/roots-example-project.com/site"]
 INFO bsd: NFS OPTS: {:type=>:nfs, :guestpath=>"/vagrant-nfs-roots-example-project.com", :hostpath=>"/Users/philip/projects/roots/roots-example-project.com/site", :disabled=>false, :__vagrantfile=>true, :map_uid=>501, :map_gid=>0, :nfs_udp=>true, :nfs_version=>3, :uuid=>"1111244617", :bsd__nfs_options=>["alldirs", "mapall=501:0"], :bsd__compiled_nfs_options=>"-alldirs -mapall=501:0"}
...
DEBUG guest: Searching for cap: mount_nfs_folder
DEBUG guest: Checking in: ubuntu
DEBUG guest: Checking in: debian
DEBUG guest: Checking in: linux
DEBUG guest: Found cap: mount_nfs_folder in linux
 INFO guest: Execute capability: mount_nfs_folder [#<Vagrant::Machine: default (VagrantPlugins::ProviderVirtualBox::Provider)>, "192.168.50.1", {"/vagrant-nfs-roots-example-project.com"=>{:type=>:nfs, :guestpath=>"/vagrant-nfs-roots-example-project.com", :hostpath=>"/Users/philip/projects/roots/roots-example-project.com/site", :disabled=>false, :__vagrantfile=>true, :map_uid=>501, :map_gid=>0, :nfs_udp=>true, :nfs_version=>3, :uuid=>"1111244617"}}] (ubuntu)
...
DEBUG guest: Searching for cap: shell_expand_guest_path
DEBUG guest: Checking in: ubuntu
DEBUG guest: Checking in: debian
DEBUG guest: Checking in: linux
DEBUG guest: Found cap: shell_expand_guest_path in linux
 INFO guest: Execute capability: shell_expand_guest_path [#<Vagrant::Machine: default (VagrantPlugins::ProviderVirtualBox::Provider)>, "/vagrant-nfs-roots-example-project.com"] (ubuntu)
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: echo; printf /vagrant-nfs-roots-example-project.com (sudo=false)
DEBUG ssh: stdout:

DEBUG ssh: stdout: /vagrant-nfs-roots-example-project.com
DEBUG ssh: Exit status: 0
DEBUG ssh: Re-using SSH connection.
 INFO ssh: Execute: mkdir -p '/vagrant-nfs-roots-example-project.com'
mount -o vers=3,udp '192.168.50.1:/Users/philip/projects/roots/roots-example-project.com/site' '/vagrant-nfs-roots-example-project.com'
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT='/vagrant-nfs-roots-example-project.com'
fi
 (sudo=true)

Maybe as you examine your output you'll see some error info, or at least some kind of lead.

[swalkinshaw]

I actually ran into this myself with Vagrant 1.8.4. I tried downgrading again and it worked with 1.8.0.

You may want to try that yourselves.

[paultibbetts]

Just a note that this is also happening with other projects, where the plan is "wait for 1.8.5"