Thanks for the explanations, Antoine. I'll have a look and see if I can figure it out. Also agree with what Robert just said that it would be nice if this was more easily configurable. Not sure what other extensions are supporting, but I'm guessing not all of them are targeting latest MW alpha.
*Sebastian Berlin* Utvecklare/*Developer* Wikimedia Sverige (WMSE) E-post/*E-Mail*: sebastian.ber...@wikimedia.se Telefon/*Phone*: (+46) 0707 - 92 03 84 On Thu, 15 Sept 2022 at 08:56, Robert Vogel via Wikitech-l < wikitech-l@lists.wikimedia.org> wrote: > @Hashar: Just wondering, are there any plans to change CI configs after > moving development/code-review from gerrit to gitlab [1]? Maybe some file > living in the repo directly rather than using a centralized repo like > `integration/config`? > > [1] https://www.mediawiki.org/wiki/GitLab/Gerrit_to_GitLab > > -- > Robert > ------------------------------ > *Von:* Antoine Musso <has...@free.fr> > *Gesendet:* Dienstag, 13. September 2022 15:42 > *An:* Wikitech-l <wikitech-l@lists.wikimedia.org>; Sebastian Berlin < > sebastian.ber...@wikimedia.se> > *Betreff:* [Wikitech-l] Re: How to specify version of MW that Jenkins > should run? > > 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 > > > > > > _______________________________________________ > Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org > To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org > https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/ >
_______________________________________________ Wikitech-l mailing list -- wikitech-l@lists.wikimedia.org To unsubscribe send an email to wikitech-l-le...@lists.wikimedia.org https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
