@Ejegg I think the reason the job failed is that it get the composer dependencies from mediawiki/vendor on branch REL1_25 which is unlikely to match the dependency list listed in the composer.json of DonationInterface.
So in theory we could remove the composer install step and have mediawiki/vendor to receive a fundraising/REL1_25 branch which would be populated using the composer dependencies for core + all extensions you use on that branch.
How would you get the dependency from DonationInterface deployed on the fundraising cluster?
@hashar, so far we've been trying to keep our shared dependencies (psr/log, monolog, lightncandy) in sync with the versions required by core. Then we're installing our own dependencies in DonationInterface/vendor, and it shouldn't matter which autoloader provides each class.
On master, we only check in composer.lock and composer.json, but on our DonationInterface deployment branch, we also have a vendor submodule that we update before deploying any dependency change. This is how we avoid running compser in our production environment and make sure we've had a chance to look at any updated dependencies.
If you do not need the features composer.lock provides then using the merge plugin (which will ignore the lock ) will create one vendor directory for core that also contains the DonationInferface dependencies. Then composer will complain if multiple dependencies contradict. A fundraising branch of vendor could be created the same way.
The job would need to be modified to drop mw-fetch-composer-dev and the composer install and then do:
- composer-validate: dir: 'src' - composer-local-create: deps: 'extensions_load.txt' - composer-update: dir: 'src'
DonationInterface has once been hacked to run composer install and eventually got migrated to use the composer-merge-plugin. And that worked fine.
fundraising/REL1_27 used an obsolete version of the plugin that did not quite work with some dependencies. However with fundraising/REL1_31 it is working just fine.