Page MenuHomePhabricator

GlobalBlocking is lacking a database installer/updater
Closed, ResolvedPublic

Description

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

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:36 AM
bzimport set Reference to bz67300.

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

https://gerrit.wikimedia.org/r/143154

Change 143154 merged by jenkins-bot:
GlobalBlocking is lacking a database installer/updater

https://gerrit.wikimedia.org/r/143154

Change 143158 had a related patch set uploaded by Hashar:
Update sql schema for sqlite

https://gerrit.wikimedia.org/r/143158

Change 143158 merged by jenkins-bot:
Update sql schema for sqlite

https://gerrit.wikimedia.org/r/143158

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!

gerritbot added a subscriber: gerritbot.

Change 189354 had a related patch set uploaded (by Paladox):
Add support for sqlite

https://gerrit.wikimedia.org/r/189354

Patch-For-Review

Change 189354 merged by jenkins-bot:
Add support for sqlite

https://gerrit.wikimedia.org/r/189354

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

https://gerrit.wikimedia.org/r/279296

In T69300#2147132, @Mattflaschen wrote:

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.

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

https://gerrit.wikimedia.org/r/279296