Talk:Continuous integration

• Talk:Continuous integration/Flow

Warnings/tests for ResourceModules used in gadgets?

This is a question I originally asked Krinkle in Telegram, and he suggested posting it publically so the answer is refindable; others might also find the answer useful too, of course.

When a ResourceModule is removed from an extension somehow, are there any automatic tests or standardized manual (or semi-manual) procedures to check that that module isn't a dependency of something else elsewhere? Like, in a different extension, or: as in my case, in a gadget?

I've made a couple of gadgets that depend on modules from extensions, and I'm wondering what would happen if those modules were removed from those extensions in the future. Would it be detected somewhere, or would it just fail silently? Jon Harald Søby (talk) 17:02, 20 December 2024 (UTC)

Patches for MediaWiki extension repos in Gerrit use Jenkins to run integration tests, both via PHPUnit and Selenium. One of the PHPUnit tests that MediaWiki core runs in all CI jobs, is ResourcesTest which checks that all "dependencies" in extension.json refer to modules that exist.

• You write a patch for extension A, and that patch removes module "ext.a.something". If another module in that same extension depends on that still, CI will fail.
• You write a patch removing "ext.a.something" in extension A, and extension B depends on that. If extension B is included in the list of extensions tested together with extension A, then CI will fail and prevent that patch from being merged. There are two main lists of extensions that decide that we test with. One is "tarball" extensions (e.g. bundled with MediaWiki core), and "WMF gate" extensions.

In addition to simple dependency relationships, we also run the PHPUnit tests and Selenium tests of those other extensions with your patch applied. So if "ext.a.something" still exists, but is changing in a way that would break extension B, that would also be caught.

We don't have any such "forward"-looking integration tests with Gadgets. This is intentional in so far that Gadgets by design are not limited to stable interfaces or code quality requirements. You can start simple with what works for you, and if/as the number of users of a gadget grows you can choose to support more wikis, skins, languages, browsers, content/page types, etc. Gadgets are not subject to delays/restrictions/review/requirements of official MediaWiki extensions, but then also can't count on MediaWiki developers proactively supporting and preventing breakage. You take on a small amount of risk that a gadget may briefly break until it is fixed, in exchange for no overhead in the form of review or requirements.

If your gadget only relies on documented public stable functions and module names designed for that purpose, then you can of course count on that not breaking. Extension A should have its own unit tests that prevent its stable contract from breaking, as further enforced by code review (except after deprecation warnings in the browser console and/or via m:Tech News announcements).

Most modules in MediaWiki core are considered stable and re-usable (e.g. mediawiki.api and mediawiki.util). But, most JS module names like ext.something inside extensions are considered internal to that extension, unless documented otherwise. So use those at your own risk! Krinkle (talk) 17:27, 20 December 2024 (UTC)