Closed anstosa closed 3 years ago
I will adjust the Travis configuration and merge this PR. (Travis is running the tasks very slowly at the moment, so it will take some time for it to run all tests)
(Travis is running the tasks very slowly at the moment, so it will take some time for it to run all tests)
I wonder if it's worth moving to Github Actions: https://news.ycombinator.com/item?id=25338983
I wonder if it's worth moving to Github Actions: https://news.ycombinator.com/item?id=25338983
Will investigate this option.
This "credit allocation" policy of Travis is not currently applied to projects on travis-ci.org (I never migrated to travis-ci.com), but they did reduce the number of simultaneous opensource builds, and backlog (for Linux builds) goes as high as 8000. (meaning 1 hour delays between "task queued" and "task started to run").
Also travis-ci.org apparently shuts down on 1 January. So yes, no option but to stop using Travis.
Ok, this change will break the currently recommended Installation procedure (composer install
in extensions/AWS/
directory). If I merge this, using Composer package of this extension will be the only working method of installation.
The reason is, aws/aws-sdk-php
has Guzzle as dependency, and composer install
in extensions/AWS/
will install another version of Guzzle than MediaWiki. Having 2 different versions of Guzzle causes issues like #29.
The line you are removing from composer.json
was ensuring that it doesn't happen.
How I plan to solve this: I will double-check and document the installation via composer.local.json. (in the MediaWiki top directory)
Then I will remove the mention of the old "run composer install in the extension/AWS/ directory" approach from installation instructions. (so we won't have to worry about this type of installation breaking)
Sweet, that's what I was going to suggest. Thanks for being so responsive!
Relevant conversation: https://github.com/edwardspec/mediawiki-aws-s3/pull/32#issuecomment-739649057