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
Maintenance class provides a method for getting a fresh reference
of the MW services container instance. Let's make use of these in
maintenance scripts now that we have it.
NOTE: There are still some static methods like in refreshLinks.php
that makes use of services that we can't use this method for now.
Change-Id: Idba744057577896fc97c9ecf4724db27542bf01c
== Adding --skip-message-purge
Follows-up d91c6627a9. Per CR and Phab comments, I don't think we
can (yet) promise a generic "--offline" mode. This seems too easy to
misuse. Both for users of the script, as well as for future development
to the script. It can fall out out of sync with requirements of the
overall system and leaves no natural place to discover what
responsibilities are being deferred and how the operator should fulfill
those duties.
We know LCStoreDB doesn't work offline, but there are likely other
aspects of this that don't yet work offline for some users. It would
require a much more rigorous refactor (and dropping signifant extension
hooks) to make this reliably offline. I'd welcome a standalone script
using only vendor libs, that does nothing other than scan directories
and build JSON/PHP/CDB files, but that's not what it is today.
What we can do is skip the one operation we know requires a live
DB connection, and (my main motivation for this commit) then document
that skipping it, require the user to perform the purge by other means
instead, since the purge itself is not actually optional.
Also, make this not a WMF-specific option in MW core, by committing
the accompanying script needed for this to work. This was previously
in the WikimediaMaintenance extension as "refreshMessageBlobs.php".
== Keeping --offline (as --no-database)
As far as I know, the purge is the only action we ran into that needed
a database connection, and important to note was that it's not optional.
I think for WMF we did not run into any other logic in our configuration
that uses a database, so --skip-message-purge should suffice. However,
I've kept the option for two reasons:
1. To recognise in some way the business need for WMF to use this
script in an offline manner, and thus document that the script
should at least have a way to work offline, even if there may be
site configurations and extensions that make this impossible, from
a core perspective we want to (experimentally) try to support this.
2. There is unimportant setup logic that happens in doMaintenance.php
where the service wiring for LBFactory is activated by default.
This seems avoidable and technical debt, but at least for now
we do need a way to skip that, so this option will continue to
have that effect.
However, I've renamed the option and inverted its promise. This is not
a promise from core *to* the user to offer an offline mode. Rather,
it is a promise *from* the user that they think nothing DB-needy is in
use.
Bug: T268698
Bug: T263872
Change-Id: I7878fdf4a901fb5e75da540293bb9df9fb508c20
