|Resolved||Jhernandez||T104318 [GOAL]: Testing practices & expose test coverage|
|Open||None||T100294 [EPIC] Encourage developers to increase code coverage|
|Resolved||Legoktm||T71685 Generate PHP code coverage reports for extensions|
|Stalled||None||T88434 generate Wikibase.git code coverage on Jenkins|
|Open||None||T74318 [Task] add possibility to generate proper phpunit coverage reports of Wikibase.git|
|Open||None||T88435 [Task] generate patch code coverage on gerrit patch-set upload for wikibase.git|
- Mentioned In
- T44510: Code coverage extremely low - technical debt
T74907: [Task] move git repositories that are dependencies of wikidata to gerrit
- Mentioned Here
- P8544 Commits by number of root directory entries touched
T223214: Start converting Wikibase extensions to use extension registration
T71685: Generate PHP code coverage reports for extensions
We have jobs running for a collection of our extensions now:
But still not Wikibase.git yet..
This is blocked on Wikibase adopting the standard directory layout, specifically what is documented at https://www.mediawiki.org/wiki/Continuous_integration/Tutorials/Generating_PHP_test_coverage_for_a_MediaWiki_extension#Requirements
Well, the three extensions included in Wikibase.git (WikibaseLib, WikibaseRepo, WikibaseClient) already follow that layout (lib/includes/, repo/includes/, client/tests/phpunit/, etc.) as far as I can tell… are you saying we need to split them into three Git repositories?
That's one possible option, yes. Or you can adopt the standard layout in one repo, but slightly reversed: includes/lib/, includes/repo/, tests/phpunit/client/. That's more up to the maintainers of Wikibase to figure out, but CI (and a growing number of tools) do assume the standard layout.
I just came back across this point while looking into T223214: Start converting Wikibase extensions to use extension registration, because the location of the extension.json file(s) for Wikibase is influenced by this as well. If we keep the current repo/includes/ etc. pattern, then there’s a clear place for the JSON files: repo/extension.json. On the other hand, with includes/repo/, the most natural (to me) placement of the JSON files would place them all in the repository root, where they would collide with each other. I guess that could be resolved by departing from the standard extension.json name and having extension-repo.json etc., but I’m not sure how ugly that is compared to other approaches…
For reference, over the past two years, 75% of Wikibase commits only touched one subdirectory, 14% touched two, 6% touched three, and 4% touched four or more (or files in the root directory). That’s excluding merge commits and l10n-bot stuff; see P8544 for details.
Some of these will be submodule updates (we have six submodules in view/lib/), but still, this seems to suggest that the Wikibase extensions aren’t as tightly coupled as I thought, and that splitting them into separate repositories might actually be an option.
There's some precedent with respect to how ConfirmEdit has "sub-extensions" in the same repo.
Thanks, that’s good to know. In Wikibase, I noticed two problems (so far) in Special:Version when putting the extension.json in a subdirectory: the “and more” entry in the authors list is no longer a hyperlink because the CREDITS file doesn’t reside next to the extension.json, and there’s no Git information because the extension.json is not in the Git repository root.
It looks like ConfirmEdit doesn’t have any solutions for these problems (the FancyCaptcha entry on meta:Special:Version exhibits them as well) – but they’re less serious there, because ConfirmEdit still has the root extension with correct Git information and author credits. In Wikibase we don’t have that, at least not with the current plan, as far as I’m aware (there’d be no general Wikibase extension in the root directory of the Git repository).
Both of the problems can be solved as far as MediaWiki is concerned by symlinking CREDITS and .git into the subdirectory, but obviously for .git that’s not a workable solution, since Git will then think the subdirectory is a Git repository root. (For CREDITS, it works well enough, though I suppose we could also have separate per-subdirectory CREDITS files if we wanted to.) Perhaps some new settings for extension.json can be added, telling the extension registry where to look for the Git repository root and possibly other information? It could either be one general setting “look in ../ for anything not found in ./” (where the ../ would be the setting’s value) or one setting for the Git repository root, one for the CREDITS file, and others for whatever other problems turn up (I probably haven’t found all of them yet).