Le 12/09/2022 à 12:20, Sebastian Berlin a écrit :
I'm having some issues with Jenkins running the
latest version of MW
for an extension (Wikispeech
<https://www.mediawiki.org/wiki/Extension:Wikispeech>). Jenkins run
with the 1.40 alpha, but we want the extension to support the latest
LTS (1.35 as of right now).
I tried changing in extension.json to:
"requires": {
"MediaWiki": "1.35.*"
}
which caused an error for Jenkins:
12:44:09 A dependency error was encountered while installing the
extension "Wikispeech": Wikispeech is not compatible with the
current MediaWiki core (version 1.40.0-alpha), it requires: 1.35.*.
The whole log is here:
https://phabricator.wikimedia.org/P34482.
How can I specify what version of MW to run with? I've looked at both
the MW wiki and Wikitech, but hasn't found any instructions for this.
Hello,
There are a lot of good answers and hints in this thread. I will
complement the answers since I am the one that has introduced the CI
system currently used for MediaWiki and I used to be in the Wikimedia
Foundation team which was responsible for MediaWiki development
(Platform Engineering, disbanded in 2015).
MediaWiki is primarily developed for the Wikimedia project and the focus
on CI is to ensure that the master branch of MediaWiki core, extensions,
skins and their composer dependencies are working well together. The CI
jobs prefixed "wmf-quibble" clone a few dozen of extensions and are
triggered whenever one send a patch to one of those extensions or
mediawiki/core. Hence we have more or less a guarantee that the master
branches of the participating repositories are all working together.
For the deployment to the Wikimedia cluster, we cut a new deployment
branch (wmf/XXX) directly from the master branch. Since a change could
only have been merged in the master branch if all the CI jobs passed, we
are pretty sure that the set of repositories with their wmf branches are
passing tests. There are some caveats still but that is the rough idea.
The MediaWiki releases are generated from the REL* branches and CI
follows the same logic. If one send a patch to their extensions REL1_35
branch, CI checkout the REL1_35 branch of mediawiki/core and any other
repositories participating in the job.
Thus if you send a patch to WikiSpeech REL1_35 you would get
mediawiki/core and Vector at REL1_35 as well ensuring everything works
well together (and by everything, I mean what ever is covered by tests).
But if you send a patch for the master branch, it is the master branch
of all repositories being checked out. In all case the value(s) of the
requires field in extension.json does not affect the branch used in CI.
It is entirely based on the convention that all repos are using the same
branch.
There are lot of use cases for developers ensuring the master branch is
compatible with the current development version (master) AND keeping
back compatibility all the way up to the latest LTS. But that is not
enforced by CI. I know Translate does it, most probably through manual
testing.
What we could potentially do is create a job which would inspect the
extension requires field to get the target branch to test (so if one
requires 1.35, target the REL1_35 branch) then invoke the testrunner
with that branch override (--branch REL1_35). Then if you send a patch
to WikiSpeech master branch, such a job would test its code against
mediawiki/core / vector using REL1_35. I am not entirely sure how to
implement it, but the best place would probably be
https://gerrit.wikimedia.org/g/integration/quibble/ It is the code
holding all the logic to clone/checkout repositories, setup MediaWiki
and run the test suite. I am guessing when a change is targeting an
extension or skin, Quibble would clone it first, inspect the
extension.json and then internally set the default branch (the
`--branch` parameter). And we can have a Jenkins job using that feature
and running along the rest of the jobs.
It will most probably be fine for extensions that do not have many other
dependencies.
The relevant task would be
https://phabricator.wikimedia.org/T196467 . I
think the devil is defining the workflow that is needed, which is more
or less the text above.
Antoine "hashar" Musso