A globalblocking.sql is provided, but it is never registered with MediaWiki updater. That prevents Jenkins from testing the installation with install.php with a sqlite backend. Will also prevent us from embedding that extension in a test job that tests all extensions together.
Version: unspecified
Severity: normal
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | hashar | T60772 common gating job for mediawiki core and extensions | |||
| Resolved | hashar | T69216 Have unit tests of all wmf deployed extensions pass when installed together, in both PHP-Zend and HHVM (tracking) | |||
| Resolved | Reedy | T69300 GlobalBlocking is lacking a database installer/updater |
We really need tests to pass when all wmf extensions are installed together. That is preventing us from progression toward the HHVM migrating. Raising priority to High.
Change 143154 had a related patch set uploaded by Reedy:
GlobalBlocking is lacking a database installer/updater
Change 143154 merged by jenkins-bot:
GlobalBlocking is lacking a database installer/updater
Change 143158 had a related patch set uploaded by Hashar:
Update sql schema for sqlite
Fixed by Reedy. The tests do not run properly because they lookup in a non existent database though. Gotta be figured out later.
Thank you Sam!
Change 189354 had a related patch set uploaded (by Paladox):
Add support for sqlite
If you run update.php on every wiki (as with MediaWiki-Vagrant), this will create the globalblocks and global_block_whitelist in every wiki's database. These tables probably won't actually get used, since it looks for them in $wgGlobalBlockingDatabase (by default 'globalblocking')..
Also, there is a local global_block_whitelist table (it won't get a double-create error due to how LoadExtensionSchemaUpdates works) that is intended to be in each wiki. Luckily, there are the exact same schema.
So if you have a multi-wiki setup, this probably will create a bunch of useless tables.
For a single-wiki setup (e.g. maybe Jenkins, I don't know), it could potentially work, only if $wgGlobalBlockingDatabase was overriden to the wiki name. Even then, the "local" global_block_whitelist and "global" global_block_whitelist are really the same table, which is not intended.
I don't see references to wgGlobalBlockingDatabase in integration/config, but maybe that's the wrong place to grep.
I'm going to put up a WIP to remove that line. Hopefully hashar can take a look.
Change 279296 had a related patch set uploaded (by Mattflaschen):
WIP: Don't create global tables on every wiki
It's set on the extension configuration file. See https://phabricator.wikimedia.org/diffusion/EGBL/browse/master/GlobalBlocking.php;9282b0e5351d18fd5de7c96635615f2cb0c4ae4b$90
Change 279296 abandoned by Mattflaschen:
WIP: Don't create global tables on every wiki
Reason:
See task