Page MenuHomePhabricator

generate Wikibase.git code coverage on Jenkins
Open, Stalled, LowestPublic

Event Timeline

JanZerebecki raised the priority of this task from to Needs Triage.
JanZerebecki updated the task description. (Show Details)
JanZerebecki subscribed.
hashar triaged this task as Lowest priority.Feb 4 2015, 9:00 AM
hashar subscribed.

Lacking spare cycles to work on it. One will have to figure out how it can be done.

@Legoktm didn't you recently do something to do with coverage of extensions?

We have jobs running for a collection of our extensions now:

  • WikibaseLexeme
  • WikibaseQuality
  • WikibaseQualityConstraints
  • WikibaseQualityExternalValidation

But still not Wikibase.git yet..

Addshore renamed this task from jenkins job to generate wikibase.git coverage to generate Wikibase.git code coverage on Jenkins.Aug 20 2018, 3:44 PM
Legoktm changed the task status from Open to Stalled.Jan 30 2019, 8:26 AM

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.

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.

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…

There's some precedent with respect to how ConfirmEdit has "sub-extensions" in the same repo.

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).

I’ve uploaded a WIP patch moving extension-view-wip.json to the view/ subdirectory, if you want to try it out.