|Resolved||JanZerebecki||T125722 Wikidata broken on branch REL1_25 causing other extensions to fail.|
|Resolved||Paladox||T126073 Wikidata QUnit broken on branch REL1_25 causing other extensions to fail|
@Mattflaschen ok will do it in a sec seems that tests on REL1_26 also fail but not as many fail. So for example scribunto fails with the same bug so I backported the change. But qunit fails with some kind of js file in core I think. also phplint fails with https://integration.wikimedia.org/ci/job/mediawiki-core-php53lint/1077/console
However, the complication is that the version with the fix (7925b64b7256902a2059273de76963d3bc3286a6) is quite different from the version currently there on REL1_25 (0.14.0).
You could create a branch based on 0.14.0, then cherry-pick 7925b64b7256902a2059273de76963d3bc3286a6 on top, but that might get complicated.
I will ask the Wikidata people whether the build bot runs on release branches like REL1_25 (it doesn't seem so), and about this bug.. If not, we may want to go with your approach of fixing it manually.
@Mattflaschen I found a better solution we could cut off unit tests with a config so I have been going through all of wikidata doing that. Ive name the config $wmgUseWikidataTest and disabled it by default. that way it isent a big change and can be done at a later point.
I don't really want to disable all QUnit on the release branches just for a missing expect count. Even manually fixing it is better than that, IMHO, if the build bot isn't running anyway.
The fix to Wikidata to make it pass that job on master was done during T117886.
This problem was created because this job didn't run for Wikidata before, so when we enabled the job it was also enabled for old release branches, even though the fix to make the job pass was only merged in master.
Builds for anything except master are done manually. You can update only one component by passing that as an argument like: composer update data-values/value-view.
So there are a few options sorting by estimated work needed in increasing order:
- Disable Wikidata and its tests on the release branches.
- Make the Job skip Wikidata on release branches. Like https://gerrit.wikimedia.org/r/#/c/268790/ but it is more complicated, as the job mediawiki-extensions-qunit also contains a list of repos it pulls in when it is triggered from other repos. This can probably be done by duplicating this and the other gate jobs with one copy per release branch, each having a different set of extensions, but that is probably more clutter than is worth for old extensions without users (otherwise it would be worth it to fix the extension instead).
- Backport fixes, which probably involves a new release of a few components branched from the version used in the release branch and at least one backport into the Wikibase release branch, then updating the Wikidata build from all that.
- Setting the release branch to the current master version via a merge. (We probably broke compatibility with older core versions often enough, that this would involve quite some changes to make things backwards compatible.)
To put this into perspective there are probably 0 users of Wikibase on release versions. I think I prefer solution 1, but find 3 acceptable (even though 3 is probably not worth the effort).
It seems https://gerrit.wikimedia.org/r/#/c/268828/ is a combination of 1 and 3, I will comment there.
We probably would need to change how new jobs are enabled so that it doesn't affect old branches, which is not a small task.
I merged https://gerrit.wikimedia.org/r/#/c/269310/ which basically disables Wikidata on REL1_25. Anyone wanting to use any of the Wikidata extensions should use them directly without the build and even then it is suggested that they use master or the current wmf release branch. However if anyone wants to use any of them or even the build with releases, I'm willing to merge patches to make that work. Also tell us, as we want to know about users :) .