Closed johnbillion closed 3 months ago
Not yet tested but could the problem be there isn't
composer run build-vendor
git add -f vendor/autoload.php
git add -f vendor/composer/*
in reusable-deploy-tag.yml
?
Because it seems that workflow installs also dev deps, which pollute the autoloader with not required files
I've identified the root cause as being the call to composer install
which was added in https://github.com/johnbillion/plugin-infrastructure/commit/13b30ba69e3e0b1e13319eadb773a23ffb47a6dc but I wasn't able to determine why 3.15 wasn't affected. This change was made prior to Query Monitor 3.15 being released. Alas the GitHub Actions run logs are only retained for 90 days so I've exhausted everything that I can investigate.
Improvements that have been made as a result:
I'm performing a root cause analysis of why the 3.16.0 release was broken so I can hopefully prevent it happening again. I'll update this issue as I go.
Problem
Version 3.16.0 was released on April 22nd. Users who updated to this version immediately reported a fatal error that caused their sites to go down.
Stack trace from a WP-CLI request:
References
Notes
plugin-infrastructure
between the two releasesRoot cause
The plugin at version 3.16.0 as shipped to wordpress.org triggered a fatal error
Why?
The
vendor/composer/autoload_real.php
was attempting to load avendor/symfony/deprecation-contracts/function.php
PHP file that does not (and should not) existWhy?
The
vendor/composer/autoload_real.php
file contains unexpected calls torequire
for a bunch of files that do not exist in the buildMain change is the addition of:
When
composer dump-autoload --no-dev
is run, the$filesToLoad
code isn't present. It's only present when the autoloader is created with dev dependencies.Why?
At the point where the Composer autoload files were last generated within the
deploy-tag.yml
orreusable-deploy-tag.yml
workflow, Composer thought those files were neededWhy?
composer install
is called within thereusable-deploy-tag.yml
workflow, which appears to be the cause of the regenerated autoloader.Why?
The above is the cause of the regenerated autoloader but I've been unable to determine why this didn't affect version 3.15 which was released after the introduction of this call to
composer install
. The logs for GitHub Actions workflow runs are only retained for 90 days.Additional issues
setClassMapAuthoritative
line (which should happen here) was also not present in the shipped release. See https://github.com/johnbillion/wp-crontrol/issues/91 for the history.Counter measures