Page MenuHomePhabricator

jjb: run composer install in DonationInterface
Closed, ResolvedPublic

Description

This changeset was brought to my attention during today's scrum of scrums: Run composer during wacky Fundraising back-compat.

Release-Engineering-Team-TODO (201907) support was requested and @JanZerebecki suggested that this could use rGCMP composer-merge-plugin (see comments on gerrit)

Event Timeline

mmodell created this task.Mar 30 2016, 5:55 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 30 2016, 5:55 PM

Change 277563 had a related patch set uploaded (by Greg Grossmeier):
Run composer during wacky Fundraising back-compat

https://gerrit.wikimedia.org/r/277563

mmodell added a subscriber: awight.Mar 30 2016, 6:02 PM

How is and will the fund raising MW installation with DonationInterface be deployed?

Change 277563 merged by jenkins-bot:
Run composer during wacky Fundraising back-compat

https://gerrit.wikimedia.org/r/277563

I am not at all familiar how it is or will be deployed. I'd be glad to help figure out a workable solution but I am not aware of the history or the current state.

hashar added a comment.Apr 4 2016, 7:01 PM

@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?

Ejegg added a comment.Apr 4 2016, 7:09 PM

@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.

Ejegg added a comment.Apr 4 2016, 7:10 PM

I do like the idea of merging our vendor changes into a branch of the core vendor submodule though!

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'
awight removed a subscriber: awight.Mar 21 2019, 4:00 PM
hashar closed this task as Resolved.Apr 17 2019, 1:24 PM
hashar claimed this task.

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.