Tool provisioner failure on master branch

[markbain]

What was The Command Used To Provision

vagrant up

What Kind of VVV Provision Was This

This was a fresh install

Logs/What Broke

/var/log/provisioners/2022.12.27_16-43-40/provisioner-tools.log

 ▷ Running the 'tools' provisioner...
 ▷ Running tools_pre_setup hook
 * [Composer]: Turning off PHP debug mods to avoid Composer performance issues
 * Restarting PHP FPM services so that the change takes effect
 ✔ All PHP Debug mods are now turned off.
 ✔ Finished tools_pre_setup hook in 1s
 ▷ Running tools_setup hook
 * [Composer]: Checking if Composer is installed
 * [Composer]: Already installed
 * [Composer]: Making sure the Composer cache is not owned by root
 * [Composer]: Checking for GitHub tokens
 * [Composer]: Checking for Composer updates
Composer version 2.5.1 2022-12-22 15:33:54
 * [Composer]: Main tasks completed, running after_composer hook
 ▷ Running after_composer hook
 * [PHPCS]: Provisioning PHP_CodeSniffer (phpcs), see https://github.com/squizlabs/PHP_CodeSniffer
Loading composer repositories with package information
Info from https://repo.packagist.org: #StandWithUkraine
Updating dependencies
Lock file operations: 8 installs, 0 updates, 0 removals
  - Locking automattic/vipwpcs (2.3.3)
  - Locking dealerdirect/phpcodesniffer-composer-installer (v0.7.2)
  - Locking phpcompatibility/php-compatibility (9.3.5)
  - Locking phpcompatibility/phpcompatibility-paragonie (1.3.2)
  - Locking phpcompatibility/phpcompatibility-wp (2.1.4)
  - Locking sirbrillig/phpcs-variable-analysis (v2.11.9)
  - Locking squizlabs/php_codesniffer (3.7.1)
  - Locking wp-coding-standards/wpcs (2.3.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 8 installs, 0 updates, 0 removals
  - Installing squizlabs/php_codesniffer (3.7.1): Extracting archive
    Skipped installation of bin bin/phpcs for package squizlabs/php_codesniffer: file not found in package
    Skipped installation of bin bin/phpcbf for package squizlabs/php_codesniffer: file not found in package
    Install of squizlabs/php_codesniffer failed

In Filesystem.php line 314:

  Could not delete /srv/www/phpcs/vendor/squizlabs/php_codesniffer:  

update [--with WITH] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--no-audit] [--audit-format AUDIT-FORMAT] [--no-autoloader] [--no-suggest] [--no-progress] [-w|--with-dependencies] [-W|--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-i|--interactive] [--root-reqs] [--] [<packages>...]

 ! The 'tools' provisioner ran into problems, the full log is available at '/var/log/provisioners/2022.12.27_16-43-40/provisioner-tools.log'. It completed in 6 seconds.

config.yml (default)

---

# This file is a YAML formatted file. YAML indenting is done in spaces not
# tabs, and whitespace is significant. If you don't stick to this, it will
# fail on provision

#
# IMPORTANT, if you change this file, you have to reprovision,  no exceptions
# Do this by running either this command:
# vagrant up --provision

# Or, if your machine is already turned on:
# vagrant provision
#

# These are your websites, and their names map on to the folders they're
# located in. See the docs for how to define these, and what all the keys
# and options are
sites:

  # latest version of WordPress, can be used for client work and testing
  # Check the readme at https://github.com/Varying-Vagrant-Vagrants/custom-site-template
  wordpress-one:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    hosts:
      - one.wordpress.test
    custom:
      wpconfig_constants:
        WP_DEBUG: true
        WP_DEBUG_LOG: true
        WP_DISABLE_FATAL_ERROR_HANDLER: true # To disable in WP 5.2 the FER mode

  wordpress-two:
    skip_provisioning: false
    description: "A standard WP install, useful for building plugins, testing things, etc"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
    php: 7.4 # change the PHP version to use for the provision and nginx
    custom:
      # locale: it_IT
      delete_default_plugins: true
      install_plugins:
        - query-monitor
    hosts:
      - two.wordpress.test

  # The following commented out site configuration will create a standard WordPress
  # site in www/example-site/ available at http://mysite.test.
  # Remember, whitespace is significant! Tabs and spaces mean different things
  #mysite:
  #  description: "My website"
  #  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  #  hosts:
  #    - mysite.test

  # The wordpress-develop configuration is useful for contributing to WordPress Core.
  # It uses the built WP to serve the site
  wordpress-trunk:
    skip_provisioning: true # provisioning this one takes longer, so it's disabled by default
    description: "An svn based WP Core trunk dev setup, useful for contributor days, Trac tickets, patches"
    repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template-develop.git
    hosts:
      - trunk.wordpress.test

  # The following commented out site configuration will create a standard WordPress
  # site in www/example-site/ available at http://my-example-site.test.
  # Remember, whitespace is significant! Tabs and spaces mean different things
  #example-site:
  #  repo: https://github.com/Varying-Vagrant-Vagrants/custom-site-template.git
  #  hosts:
  #    - my-example-site.test

# Extensions https://varyingvagrantvagrants.org/docs/en-US/utilities/
# are system level items that aren't websites, that install tools or packages
# the core extensions install tools such as phpmyadmin or new PHP versions
#
# these used to be called utilities but people kept requesting
# extensions not realising so it was renamed
extensions:
  core: # The core VVV extensions
    - tls-ca # HTTPS SSL/TLS certificates
    - phpmyadmin # Web based database client
    #- memcached-admin # Object cache management
    #- opcache-status # opcache management
    #- webgrind # PHP Debugging
    #- mongodb # needed for Tideways/XHGui
    #- tideways # PHP profiling tool, also installs xhgui check https://varyingvagrantvagrants.org/docs/en-US/references/tideways-xhgui/
    #- nvm # Node Version Manager
    #- php56
    #- php70
    #- php71
    #- php72
    #- php73
    #- php74
    #- php80

# vm_config controls how Vagrant provisions the virtual machine, and can be used to
# increase the memory given to VVV and the number of CPU cores.
# It can also be used to override the default provider being used within Vagrant.

vm_config:
  # For WP core development we recommend at least 2GB ( 2048 ),
  # If you have 4GB of RAM, lower this to 768MB or you may encounter issues
  #
  # For theme or plugin development 2GB is more than enough for page loads,
  # if you need more for web requests consider reducing your memory footprint.
  #
  # More memory won't speed things up.
  memory: 2048

  # How many virtual CPU cores, does not apply to Docker. Additional CPU cores
  # will only have a performance impact if you have those cores to spare and are
  # running heavy CLI tasks
  cores: 2

  # this tells VVV to use the prebuilt box copied from the USB drive at contributor days
  # once set to false, do not change back to true, and reprovision
  # wordcamp_contributor_day_box: false

  # Due to a limitation within Vagrant, the specified provider is only respected on a clean `vagrant up`
  # as Vagrant currently restricts you to one provider per machine
  # https://www.vagrantup.com/docs/providers/basic_usage.html#vagrant-up
  # provider: virtualbox
  # provider: hyperv
  # provider: parallels
  # provider: vmware_desktop

# General VVV options
general:

  # Back up Options
  # You can always backup/restore manually using vagrant ssh -c "db_backup" or vagrant ssh -c "db_restore"

  # Backup the databases to the database/backups subfolder on halt/suspend/destroy, set to false to disable
  db_backup:
      enable: false
      gzip: true
      #exclude:
      #  - wordpress-trunk

  # Import the databases if they're missing from backups
  db_restore: false

  # set to true to use a synced shared folder for MariaDB database storage
  db_share_type: false

  # GitHub token to use from composer
  #github_token: xxxxxx

# Settings for the vagrant plugins supported by VVV
vagrant-plugins:
  disksize: 10GB # requires the disk size vagrant plugin

Provisioning output: https://gist.github.com/markbain/4b54674266a4c2c35c4347c796c75cfc

Steps to Reproduce (for bugs)

It's just a clean install i.e.

1. git clone -b stable https://github.com/Varying-Vagrant-Vagrants/VVV.git ~/vvv
2. cd ~/vvv-local
3. vagrant plugin install --local
4. vagrant up

Your Environment

v3.9.1 Path:"/home/mark/code/vvv"
 \_/\_/\_/  git::master(8b46bc24)

Platform: linux shell:/usr/bin/zsh systemd  vagrant-goodhosts CaseSensitiveFS shared_db_folder_disabled
Vagrant: v2.3.4, virtualbox: v5.2.42

[welcome[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template and include your OS/Vagrant/VVV versions! Don't forget you can get support in the VVV slack at https://varyingvagrantvagrants.org/docs/en-US/slack/

VVV

VVV Slack Workspace

Join the VVV Slack Workspace

[tomjn]

@markbain v3.9.1 is out of date, can you retry this using the current version v3.10.1?

I also see you're using an unsupported branch master and not the official release branches of stable and develop

[markbain]

@tomjn Sorry, I've been messing about trying different branches, but this issue did occur on stable. I've switched back, now showing:

v3.10.1 Ruby:2.7.6, Path:"/home/mark/code/vvv"
 \_/\_/\_/  git::stable(5b3aa204)

Platform: linux shell:/usr/bin/zsh systemd  vagrant-goodhosts CaseSensitiveFS shared_db_folder_disabled
Vagrant: v2.3.4, virtualbox: v5.2.42

Ran another vagrant up --provision to be sure, and getting the same output.

[markbain]

I've also tried on the develop branch.

[tomjn]

@markbain the PHPCS folder is actually in a shared folder under www, you can just delete it and re-provision.

As for the master branch, consider it abandoned, I've just set up a PR at https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2647 that replaces the entire vagrant file with a prompt to switch to stable

[markbain]

@tomjn Exactly the same thing happening in the stable branch. I've tried deleting the PHPCP folder, but it makes no difference.

[tomjn]

I'm not interested in the stable branch, only the develop branch, if you delete the www/phpcs folder and its contents, then vagrant up --provision what's the full output of the tools provisioner?

[tomjn]

Also virtualbox: v5.2.42 is quite an old version, VirtualBox v7.04 is the latest version

[tomjn]

a reprovision of develop doesn't reproduce the issue locally here, I'm running MacOS + Parallels though

[tomjn]

If that fails, vagrant ssh then composer clearcache and reprovision. You may also want to upgrade VirtualBox, it's a very old version and you may find the box being used has much newer guest additions causing filesystem problems.

I've also made some adjustments in https://github.com/Varying-Vagrant-Vagrants/VVV/pull/2648 but these are not what I would call "fixes", but rather general maintenance. None of the changes should cause or fix the problem you're encountering. My suspicion is the VirtualBox version you're using but I haven't anything to work with on that theory yet.

[markbain]

@tomjn I thought I was on the latest version of Virtualbox based on checking for updates via the GUI, but it seems I wasn't. Upgrading to 7.0.4 has done the trick. Thanks for your help.