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

Details

Reference
bz67300

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:36 AM
bzimport set Reference to bz67300.
hashar created this task.Jun 30 2014, 1:30 PM

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

Mattflaschen-WMF reopened this task as Open.Mar 24 2016, 2:45 AM

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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 24 2016, 2:45 AM

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

Mattflaschen-WMF closed this task as Resolved.Mar 31 2016, 12:07 AM