Provisioning breaks saying `extension-source-core` ran into problems

[fullofcaffeine]

What was The Command Used To Provision

vagrant up --provision 

What Kind of VVV Provision Was This

This was a fresh install

Logs/What Broke

It fails in this step:

    default:  ✔ The 'dashboard' provisioner completed in 0 seconds.                                      
==> default: Running provisioner: extension-source-core (shell)...                                       
    default: Running: /tmp/fullofcaffeine/vagrant-shell20220421-13533-181j8p6.sh                         
    default:  ▷ Running the 'extension-source-core' provisioner...                                       
    default:  * Updating the "core" extension on the "master" branch...                                  
    default: fatal: unsafe repository ('/srv/provision/extensions/core' is owned by someone else)        
    default: To add an exception for this directory, call:                                               
    default:                                                                                             
    default:    git config --global --add safe.directory /srv/provision/extensions/core                  
    default:  ! The 'extension-source-core' provisioner ran into problems, the full log is available at '
/var/log/provisioners/2022.04.22_01-36-14/provisioner-extension-source-core.log'. It completed in 0 secon
ds.                                                                                                      
The SSH command responded with a non-zero exit status. Vagrant                                           
assumes that this means the command failed. The output for this command                                  
should be in the log above. Please read the output to determine what                                     
went wrong.                                                                  

• config/config.yml:

---

# 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
    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

config/config.yml goes here

Possible Solution

Steps to Reproduce (for bugs)

1. Clone VVV and checkout the 3.8.1 tag. cd to its root dir.
2. vagrant up --provision
3. It seems to provision well, until it breaks like shown above.

Your Environment

__ __ __ __
\ V\ V\ V / v3.8.1 Path:"/home/fullofcaffeine/workspace/code/VVV"
 \_/\_/\_/  git::heads/3.8.1(0a2accce)

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

OS: Ubuntu Linux 18.04

[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/

[tomjn]

3.8.1 is an old version, this problem is fixed in 3.9.1 and above

On Fri, 22 Apr 2022 at 03:03, welcome[bot] @.***> wrote:

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/

— Reply to this email directly, view it on GitHub https://github.com/Varying-Vagrant-Vagrants/VVV/issues/2602#issuecomment-1105927590, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAOLZ6KVGGWLT2BLGBHWULVGICG7ANCNFSM5UA5CWMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[fullofcaffeine]

Hi! Thanks for letting me know! I've updated to 3.9.1, but I'm still getting a provisioning error, in the after_composer hook:

   default:  * [Composer]: Main tasks completed, running after_composer hook
    default:  ▷ Running after_composer hook
    default:  * [PHPCS]: Provisioning PHP_CodeSniffer (phpcs), see https://github.com/squizlabs/PHP_CodeSniffer
    default: Loading composer repositories with package information
    default: Info from https://repo.packagist.org: #StandWithUkraine
    default: Updating dependencies
    default: Lock file operations: 2 installs, 0 updates, 0 removals
    default:   - Locking phpcompatibility/phpcompatibility-paragonie (1.3.1)
    default:   - Locking phpcompatibility/phpcompatibility-wp (2.1.3)
    default: Writing lock file
    default: Installing dependencies from lock file (including require-dev)
    default: Package operations: 8 installs, 0 updates, 0 removals
    default:   - Downloading squizlabs/php_codesniffer (3.6.2)
    default:   - Downloading dealerdirect/phpcodesniffer-composer-installer (v0.7.2)
    default:   - Downloading wp-coding-standards/wpcs (2.3.0)
    default:   - Downloading sirbrillig/phpcs-variable-analysis (v2.11.3)
    default:   - Downloading automattic/vipwpcs (2.3.3)
    default:   - Downloading phpcompatibility/php-compatibility (9.3.5)
    default:   - Downloading phpcompatibility/phpcompatibility-paragonie (1.3.1)
    default:   - Downloading phpcompatibility/phpcompatibility-wp (2.1.3)
    default:   - Installing squizlabs/php_codesniffer (3.6.2): Extracting archive
    default:     Skipped installation of bin bin/phpcs for package squizlabs/php_codesniffer: file not found in package
    default:     Skipped installation of bin bin/phpcbf for package squizlabs/php_codesniffer: file not found in package
    default:     Install of squizlabs/php_codesniffer failed
    default: 
    default: In Filesystem.php line 330:
    default: 
    default:   Could not delete /srv/www/phpcs/vendor/composer/:
    default: 
    default: 
    default: update [--with WITH] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--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>...]
    default: 
    default:  ! The 'tools' provisioner ran into problems, the full log is available at '/var/log/provisioners/2022.04.22_16-03-11/provisioner-tools.log'. It completed in 7 seconds.
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

[fullofcaffeine]

I deactivated the provisioning of squizlabs/php_codesniffer and now the provisioning finished. Something is wrong with that step 🤔 that sounds like a feasible workaround for now, though.

[tomjn]

@fullofcaffeine we've just released 3.10.1, does this still happen on upgrade?

[tomjn]

closing due to lack of feedback, if this still happens though let us know by reopening

[fvr6]

deactivated the provisioning of squizlabs/php_codesniffer

How?

[tomjn]

@fvr6 this is an old issue, are you using the latest and greatest VVV stable release v3.10.1? This should not be an issue, especially since you can wipe/delete/nuke the phpcs folder which is in a subfolder of www and is dynamically recreated/