Today
A patch to mediawiki/core runs two kinds of jobs:
- Jenkins jobs that freshly install the latest third-party dependencies from packagist.org based the constraints in composer.json, and then run all PHPUnit tests with that.
- Jenkins jobs that download mediawiki/vendor.git, verify its lock file to be compatible, and then run with that.
They differ in exact versions of dependencies, since some ranges allow multiple versions.
Except.. this isn't what happens today. In reviewing https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1054944, which increments a mediawiki/core dependency across a semver-major version (wikimedia/less.php 4.x to 5.0), there was no failure in the mediawiki-vendor job.
Now, comparing this to:
This is claiming the exact opposite, by saying it's vendor that skips the checks and core will do them instead.
Unfortunately both of these are correct in describing what they do, which means neither performs the checks anymore. It appears this has been broken since November 2023.
Background
From T333412: mediawiki/vendor can't be updated due to phpunit reporting composer.lock failure in https://gerrit.wikimedia.org/r/c/integration/quibble/+/903832:
# In the mediawiki/vendor update workflow, we patch vendor (and its # lock file) first, and update the mediawiki/core composer.json after. # As such, when testing mediawiki/vendor, it's normal that its lock # file doesn't match mediawiki/core. This is tested by the # mediawiki/core commit instead. # # T333412 if use_vendor: os.environ['MW_SKIP_EXTERNAL_DEPENDENCIES'] = '1'
It appears this has conflated the source with the destination.
It should be bypassing the check when running patches to the mediawiki/vendor repository.
Instead, it is bypassing the check for all mediawiki/core patches in the job that uses mediawiki/vendor. The check is neccessary there, since that's why we use Depends-On, and why it is generally safe to merge composer changes in mediawiki/core, and why the part where extra care is needed is in mediawiki/vendor. However, right now composer changes in core are unprotected and unverified.