We renamed many classes to be namespaced, but the `@covers` and
`@coversDefaultClass` annotations weren't updated properly.
PHPUnit didn't support short cover annotations with `use` statements,
these didn't trigger any errors yet, because they are class alias.
This patch is populated by a modified version of PhpunitAnnotationsSniff.
Change-Id: I6c602290a30099239b17d2dc0d67b1488b4eaeeb
It's going to be a bit small and narrow but it's better than sitting in
the root of includes/ plus I hope we can hollow out SiteStatsUpdate
class into the third one and or move this under a better directory in
the future.
Bug: T321882
Change-Id: Ia503b53b31ca00600f8c18b61a2652c3e146494e
The function SiteStats::salvageIncorrectRow is a noop,
the variable $map is not returned, instead the unmodified $row is
returned, function added in 6535091
self::doLoadFromDB on second attempt after the initialize (via
doPlaceholderInit or doAllAndCommit) returns a valid row, making this
extra check no longer needed (possible since 27c76fa).
Fix doLoadFromDB on first attempt for empty table, broken since 5156ae0
Change-Id: Iec2b4bbdb2ca546eb377a6d12106d62b5219886f
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
Done with `composer fix` and suppressing the rest (i.e. sniffs for
global variables, which for core should be suppressed anyway).
Additionally, add `-p` to `phpcbf`, as otherwise it just seems stuck.
Change-Id: Ide8d6cdd083655891b6d654e78440fbda81ab2bc
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
Simplify the code of jobs that do not care about titles and removes
the direct Title dependency from JobQueue. Remove getTitle() from
IJobSpecification itself. Move all the Job::factory calls into a
single JobQueue::factoryJob() method.
Depends-on: Iee78f4baeca0c0b4d6db073f2fbcc56855114ab0
Change-Id: I9c9d0726d4066bb0aa937665847ad6042ade13ec
This should fix the flaky unit test 'SiteStatsTest::testJobsCountGetCached',
which fails locally as follows, when run in isolation.
> 1) SiteStatsTest::testJobsCountGetCached
> A single job enqueued bumps jobscount stat to 1
> Failed asserting that 2 matches expected 1.
>
> /var/www/mediawiki/tests/phpunit/includes/SiteStatsTest.php:22
> /var/www/mediawiki/tests/phpunit/MediaWikiTestCase.php:421
> /var/www/mediawiki/maintenance/doMaintenance.php:94
Instrumenting JobQueueMemory::doBatchPush reveals the following
jobs to have been queued.
- MediaWikiTestCase->run/->addCoreDBData/::getTestSysop/..
../User->addGroup/UserGroupMembership->insert/..
> UserGroupExpiryJob (2)
- MediaWikiTestCase->run/->addCoreDBData/WikiPage->doEditContent/..
../WikiPage->{closure}/WikiPage->doEditUpdates/JobQueueGroup->lazyPush/..
> CategoryMembershipChangeJob
> HTMLCacheUpdateJob (2)
Fix this by adding clearing of job queues to doLightweightServiceReset()
in MediaWikiTestCase.
Also:
- Move the call to doLightweightServiceReset() from run() to setUp(),
where it is easier to understand in context. It still runs at the same
logical point because PHPUnit calls setUp() right before run().
- Remove redundant reset for WANObjectCache->clearProcessCache that
was both in setUp() and in doLightweightServiceReset().
- Simplify SiteStatsTest by removing the hardcoded delete() calls.
An alternative fix for the flaky unit test would've been to add
a delete() call to categoryMembershipChange, but rather than hardcoding
all possible jobs that TestCase or another test could make, it's easier
to just reset/delete them all between tests.
- Simplify SiteStatsTest by using the $cache reference directly instead
of roundtripping through MediaWikiServices. If for some reason
setService() didn't work, the test will fail either way because it must
match the one used by JobQueueGroup (TODO: Use injection!), and besides
the setService() method already has its own unit test.
Change-Id: Ia4b7871221c76c65eacf31915b515705a36940d5
Each expired row has to be fetched from the user_groups table, deleted
from that table and added to the user_former_groups table. Per Jaimes
request, let's not do this for all rows at once but for smaller chunks
and wait for replication to catch up after each chunk has been
processed. In addition the function to purge the expired rows now sets a
lock so that there won't be multiple concurrent runs.
Also, cleaning this table up isn't urgent and thus should be done in a
job and not a deferred update, so let's move it there.
Bug: T176754
Change-Id: I671d4b9d09677a2f474477ba7fea33a44d6318aa
SiteStatsTest::testJobsCountGetCached() is somewhat flaky in that if it
runs after a test that adds a page (thereby producing htmlCacheUpdate
and recentChangesUpdate jobs) but doesn't have the CI framework reset
the `page` tables (which has the side effect of clearing all such jobs),
it will fail.
This change manually clears those jobs so it doesn't depend on test
ordering.
Change-Id: I1277e633c81b29bda7564fa12d23f13ded7298c7
The method hits the jobrunner backend to find out how many jobs are
enqueued in each of the JobQueue. It is publicly available via the
MediaWiki API request:
/w/api.php?action=query&meta=siteinfo&siprop=statistics
That is often used by bots when querying recent changes among other and
with fast bot cause useless queries toward the jobrunner backend.
Wrap SiteStats::jobs() with a WAN cache under key SiteStats:jobscount.
Drop SiteStats::$jobs private variable that was used for in process
cache. The WAN Cache does it for us via 'pcTTL'.
That is similar to SiteStats::numberingroup().
Set TTL to one minute, which should still give fresh enough results for
public uses.
Cover that behavior with a test.
When writing tests I noticed MediaWikiTestCase generates a few jobs due
to the creation of the UTPage page:
* HTMLCacheUpdateJob to refresh backlinks (eg: history)
* RecentChangesUpdateJob which happens randomly
Pass EDIT_SUPPRESS_RC to doEditContent to prevent the first and blindly
delete entries in the recentChangesUpdate jobqueue for the second.
Change-Id: I95a272d0691d779bfee9e7a671cbab66a113dfa1
