| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
F–P. Still need to do P–Z.
there's a couple spots where I added `use
MediaWiki\Maintenance\LoggedUpdateMaintenance;` or similar instead.
some of the existing "use" blocks were in weird spots (e.g. above the copyright
docblock, or too far down). i didn't move those because they are out of scope
for this patch.
Change-Id: I5b6a8f3eae5be85d67bccfcce31c0c2027850f45
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
|
| |
|
|
|
|
|
| |
This was somehow left out
Bug: T210206
Change-Id: I70851b5b99fa865dbfd629caf2c1866c85418350
|
| |
|
|
|
| |
Bug: T353219
Change-Id: I98bf4c2e2c3023fba226ac10826e52a1108b8aea
|
| |
|
|
|
|
|
| |
This adds reconfiguring db pools in case a replica gets depooled
Bug: T298485
Change-Id: Id052ce8ed45c51e51b071778858d27b48605bf93
|
| |
|
|
|
|
|
|
|
|
|
| |
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
|
| |
|
|
|
|
|
|
| |
This is important in long-running script so we can pick it up where it
had to be stopped or crashed (db read-only for example).
Bug: T275246
Change-Id: I7c9330c447bbd857f57b12ffb241b8e64ddbfada
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- waitForReplication is critical in such scripts, it has caused a major
outage in commons before.
- The extra sleep is not important for scripts that take a couple of
hours to finish but it is important for ones that take more than a
day. Because replication lag to secondary datacenter and non-core dbs
(cloud, backup source, analytics) is not reflected in waitForReplication
and running a maint script for an extended period of time will cause
issues for those.
You can see similar work done on similar scripts such as deleteAutoPatrolLogs.php
Bug: T275246
Change-Id: If6aa0aaadc62949c151a1f675f8aa24041bf3738
|
|
|
Introduce a new schema migration stage in which rev_actor is used
directly and the revision_actor_temp table is no longer needed. This
becomes the new "new" stage whereas the previous situation is now
termed SCHEMA_COMPAT_TEMP.
Introduce migrateRevisionActorTemp which copies data from
revision_actor_temp to rev_actor. The code is similar to
migrateImageCommentTemp.php except that it doesn't delete from the old
table.
Partial revert of c29909e59fd89d9fc6. That change removed direct
references to $wgActorTableSchemaMigrationStage and made queries
involving revision_actor_temp be unconditional. Such changes need to be
reverted to make the use of revision_actor_temp be conditional again.
In ActorMigrationTest, I compacted provideGetJoin() and
provideGetWhere(), removing most of the duplication between expected
values. I gave all the stages a short name, and mostly used the name in
providers.
Bug: T275246
Change-Id: I7498107dd6433ab7de5bf2e7b3fe2aa5e10e345d
|
