| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I2c1bc3b4e0ee782076ddaeae133672b730d345d9
|
|
|
|
|
|
|
| |
Found via disabling phan's alias support for a run (and ignoring wgLang's
hard-coded state of being a \Language, alas).
Change-Id: I4753bcd84d72d6de111fc7ffc5841fa417bf7333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same as Ia294bf4 did for 1-line comments. This patch removes slightly
more complex 2-line PHPDoc comments that don't add any new information
to the code, but literally repeat what the code already says.
They say "don't document the code, code the documentation", and we
are doing this more and more. We just tend to forget to remove the
obsolete comments.
Note I'm also removing a line of text in a few cases when it's very
short and literally says the same as the method name. Again, such
comments add zero new information.
Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I assume these are all either auto-generated by an IDE or the
language-level type declarations have been added later. In any case
the comments don't add any new information to what the code already
says. This is just extra clutter that makes the code harder to read,
I would argue.
There are many, many more comments like this. In this patch I
intentionally focus on the most trivial 1-line comments.
Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
|
|
|
|
|
|
|
|
|
|
|
|
| |
This centralizes the action of emitting stats to a single
static function to be used by web and maintenance jobs alike.
* Rename emitBufferedStatsdData to emitBufferedStats
* Move StatsFactory->flush() call into emitBufferedStats
* Update call signature where used
Bug: T380609
Change-Id: I63e8832a170bfaa0e14e977f0852c4ef49f232bb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
* The MaintenanceRunnerTest class tests using real maintenance
scripts and the code being tested can include the maintenance
script files.
* However, if running all tests together (such as when generating
test coverage) the maintenance scripts may have already been
loaded by integration tests that exist for those scripts.
* Instead of fixing the specific instances, we should instead
ensure that (where necessary) the MaintenanceRunnerTest tests
using fake maintenance scripts only loaded by that test class.
* Doing this prevents the files from being loaded anywhere else
and ensures that the tests should not fail in this way again.
What:
* Update MaintenanceRunner::expandScriptFile to move the use of
MS_INSTALL_PATH to a protected method that can then be mocked
in MaintenanceRunnerTest.
* Update MaintenanceRunnerTest to use fake maintenance scripts
where necessary. This includes:
** No longer setting the current working directory as the
MW_INSTALL_PATH, but instead set it as __DIR__.
** Creating several fake maintenance scripts to replace the uses
of the real ones.
** Updating the data providers to reflect the changes.
Bug: T371188
Change-Id: Ifacdcb8de5af53d2d5f4ed354af0d209384d7325
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the following test cases in MaintenanceRunnerTest.php:
yield 'extension script path, using prefix'
=> [ 'FakeExtension:fakeScript.php', FakeScript::class ];
// NOTE: assumes the class has been loaded by the previous test case!
yield 'extension class, using prefix'
=> [ 'FakeExtension:FakeScript', FakeScript::class ];
…the noted assumption did not quite hold on Windows.
After including …/fakeScript.php, the class was indeed loaded. The
next case would use the loaded class, but before it did that, it
first tries to include …/FakeScript.php - which doesn't exist, but
it's the same as …/fakeScript.php on case-insensitive filesystems,
so the file was loaded twice, causing "Fatal error: Cannot declare
class MediaWiki\Extension\FakeExtension\Maintenance\FakeScript,
because the name is already in use in …\fakeScript.php on line 0".
Re-order some code in MaintenanceRunner, so that it tries to use the
existing class (or autoload it) before it tries to include the file.
Change-Id: Ic7ed7139bbede48097df59338c82688081688c3b
|
|
|
|
|
|
|
|
| |
The global variable is now exactly the same as
`MW_ENTRY_POINT === 'cli'`.
Bug: T313841
Change-Id: I254bf4aa426e4834705be351cc9eb06d18a33f79
|
|
|
|
|
|
|
|
| |
I'm not sure if there's a good way to split this up into
logical chunks.
Bug: T313841
Change-Id: I3b35a2e475b5143f383d4085fbc6a0ed3bbc32b8
|
|
|
|
|
| |
Bug: T166010
Change-Id: Ibd40734b96fd2900e3ce12239d09becfb4150059
|
|
|
|
|
| |
Bug: T166010
Change-Id: I4066885a7ea071d22497abcdb3f95e73e154d08c
|
|
|
|
|
|
|
|
|
|
|
|
| |
The shutdown logic intuitively feels like the job of the runner and
the maintenance script themselves don't need to have knowledge about
this routine.
Maintenance script should really only execute their tasks after being
invoked by the runner and leave the runner to clean the house at the
end of their execution. Hence shifting the logic to the runner class.
Change-Id: I3d6fbf02b5fcd1414fde3a84e98a08e58456d668
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Start using `class-string<ClassName>` as a type hint in a few places
where the information is really helpful. A lot of tools are able to
understand this already.
Change-Id: Ide45cae8c7875e664fab1155c6c720e515d8d811
|
|/
|
|
|
|
|
|
|
|
| |
Same as I7a82951.
overrideConfigValue() and overrideConfigValues() both call
setMwGlobals(), which calls resetServices(). This is surprisingly
expensive. It's much better to call it once with an array.
Change-Id: I4ff2f6b902b1a1e0b554ce6fc76f3b612f703fae
|
|
|
|
|
|
|
| |
Reduce potential for confusion between file names and class names in
MaintenanceRunner.
Change-Id: I8be566925beced6ef6f1075e430d6afc38dbae6b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If possible, load the script file before running Setup.php. This way,
script files can control the setup process by defining constants. This
is needed by scome scripts, namely:
- instal.php, to override config loading by defining MW_CONFIG_CALLBACK
- generateConfigSchema.php, for setting MW_USE_CONFIG_SCHEMA_CLASS
- mergeMessageFileList.php, for setting MW_NO_EXTENSION_MESSAGES
- shell.php, for setting MW_NO_SESSION
Note that this will not work for scripts defined in extensions.
In order to allow script files to be loaded based on class name,
AutoLoader.php is included before Setup.php is run.
This is a modified version of I638f99c3cc6f8ab8216bd65ada959a6a11ff454b.
Co-authored-by: PleaseStand <pleasestand@live.com>
Change-Id: I2bf3b91c0a7162413cd1392252cb4f29a0d3d594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subclasses of Maintenance that can function without database access can
now override canExecuteWithoutLocalSettings to return true.
This is useful for scripts that need to be able to run before or without
installing MediaWiki.
When no config file is present, the storage backend will be disabled.
Any attempt to access the database will result in an error.
NOTE: This makes MediaWikiServices::disableBackendServices() more
comprehensive, to avoid premature failures during service
construction. This change makes it necessary to adjust how the
installer manages service overrides.
The CLI installer is covered by CI, I tested the web installer
manually.
Change-Id: Ie84010c80f32cbdfd34aff9dde1bfde1ed531793
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the replacement for the check I added in b0647c30bc30874c and
removed in I8032ab18cb26d92e:
If an Exception or Error occurs while the Maintenance object is being
constructed, or during the call to setName(), print an error message
with a reminder that scripts need to call parent::__construct(), and
also the exception details normally displayed and/or logged by PHP's
default error handler, then exit with a nonzero status.
I think this should work well enough. More precise targeting of the
reminder message likely would involve some sort of ugly hack and is
probably not necessary. It simply wouldn't be worth it, given that
the defective constructor likely would be in the stack trace anyway.
Follows-up 5bfa31187b266f83 and a9f47fd5ad4ea668.
Change-Id: I5a4ee2b23e99e195469cf258ae3833d8e18bc7b8
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* Move the PHP_SAPI check to the earliest convenient point in
Maintenance.php, well before we attempt to access $argv.
* Remove the register_argc_argv check altogether; we don't allow "cgi"
SAPI to be used for running scripts from the command line any more.
Any value from php.ini is overridden by "cli" and "phpdbg" SAPIs:
https://www.php.net/manual/en/features.commandline.differences.php
https://github.com/php/php-src/blob/php-8.2.1/sapi/phpdbg/phpdbg.c#L991
And using "-d register_argc_argv=0" or similar seems unlikely.
* Don't check if $IP is null (reverts b0647c30bc30874c). This specific
check is not useful any more, as $IP is now initialized before the
Maintenance object is constructed, and addOption() and similar methods
happen to generate PHP errors in the described situation. If desired,
a check serving the same purpose could be added in a separate commit.
Change-Id: I8032ab18cb26d92ee01ab9851ea1d45b3f9eadbf
|
| |
| |
| |
| | |
Change-Id: I1bf2ac8888863624064dd6c8ec63d95f99aedd0d
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Extract much of the logic into separate private methods for reusability
within this class (see I638f99c3cc6f8ab8):
* splitScript() splits a script name into $extName and $scriptName. It
does not check if the extension is present on the system.
* expandScriptClass() determines the class name that a given script name
may refer to. It does not attempt to load the class.
* expandScriptFile() determines the file name that a given script name
may refer to. It does not attempt to include the file.
Change-Id: I0e4530b597f8f6a753c25b3a507428fe78fb66fb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows a file in the maintenance dir to be specified without the
path but with the .php extension. Previously, the file would be expected
to be found in the local directory if it had no path but a .php
extension.
This effectively makes it so that the maintenance directory is used as
the default location for maintenance script files, which can be
specified with or without .php extension. The extension is no longer
significant for how the file is located. Only paths that start with
"./" or "../" are treated as relative to the cwd.
Depends-On: Ic1ca796a52a0c5d7095e607fdc2e320b086229c7
Bug: T326800
Change-Id: Id334d2b3ccd4be1443d95eb40b028f25c47f94c0
|
|/
|
|
|
|
|
|
|
|
|
| |
This improves the error message produced by run.php when a script is not
found or cannot be executed.
In particular, this fixes the isse that run.php would say it can't find
a script even if the script was indeed found, but was a "plain" php
script that doesn't set $maintClass.
Change-Id: Ia45c7fdaf3f7f631f8267e7e645f13fe672955f4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
== Status quo
In web requests we have:
* Setup.php: Load LocalSettings.php (CommonSettings.php in prod),
which may assign $wgProfiler, e.g. if X-Wikimedia-Debug is used.
* Setup.php: Pass global to Profiler::init().
No Profiler::instance() singleton calls exist until after this point,
which is good as otherwise it'd initialise the singleton incorrectly.
In maintenance scripts, today we have the following broken sequence:
* doMaintenance: Load MaintenanceRunner.
* MaintenanceRunner: Register the '--profiler' option.
* doMaintenance: Define MW_FINAL_SETUP_CALLBACK.
* doMaintenance: Load Setup.php.
* Setup.php: Load LocalSettings.php
* Setup.php: Call MW_FINAL_SETUP_CALLBACK
** calls MaintenanceRunner::setup
** calls MaintenanceRunner::activateProfiler
** this constructs the Profiler object directly (duplicating Profiler::init)
and saves the singleton via Profiler::replaceStubInstance.
The activateProfiler() method also uses the singleton to enable
outputting of results at shutdown, and set Rdbms warning limits.
* Setup.php: Call $wgSettings->apply().
* Setup.php: Pass global to Profiler::init().
** It wipes the singleton we just made.
** It re-creates it based on $wgProfiler, which MaintenanceRunner
failed to overwrite (it used to, but this was lost when
SettingsBuilder and MaintenanceRunner were introduced).
** It explicitly forces ProfilerStub in CLI mode, thus even if
$wgProfiler was assigned, it would still not work.
== Change
The above made sense prior to the MaintenanceRunner and
SettingsBuilder refactoring when more of Setup.php ran before
Maintenance began doing its thing, and thus it made sense that
Setup's Profiler::init call would force stub for CLI mode, and then
let Maintenance use replaceStubInstance to replace it afterward, but
the order has changed.
I'm using this oppertunity to get rid of the "replace afterwards"
approach and instead use SettingsBuilder to set wgProfiler correctly
in the first place, and further more recognise the concept of
CLI-enablement as an explicit (internal) option to avoid a conflict
between these two requirements.
Note that this isn't the first time it broke. It also broke some time
before 2014 when change I35faedff818af2ad45 restored its behaviour.
== Test plan
* Using MediaWiki-Docker which includes tideways_xhprof, and set the
snippet in LocalSettings to set $wgProfiler:
<https://www.mediawiki.org/wiki/MediaWiki-Docker/Configuration_recipes/Profiling>
* Confirm that view-source:/wiki/Main_Page contains no profiler output.
* Confirm that view-source:/wiki/Main_Page?forceprofile=1 does.
* Confirm that `php maintenance/showJobs.php` and
`php maintenance/showJobs.php --profile text` both don't print
a profile today.
* Apply this change.
* `php maintenance/showJobs.php --profile text` now prints a profile.
Change-Id: Ia1a86f0443bf7ae746811e9de5dda89f20ad446f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notable changes:
* In SqlBagOStuff::getConnectionFromServerInfo, only two loggers were
injected. The rest implicitly got a NullLogger due to being absent.
These are now effectively unsilenced.
* Database::__construct() required almost all parameters, even the
loggers. I've wanted to move some of DatabaseFactory into the ctor
here for a while. In order to make this change not a breaking
change, the new 'logger' parameter is optional with NullLogger as
default. This allowed some of the test cases, which were simply
passing NullLogger, to be fixed by passing nothing instead of
passing the new option name.
The Database class is behind a dozen layers of indirection for
real use, so this will still be injected just fine (DBF, LB, LBF,
MWLBF, etc.).
* In LegacyLogger, the handling for $wgDBerrorLog was previously
limited to DBConnection and DBQuery. This now includes errors
from other (generally, newer) parts of Rdbms as well, which were
previously missing.
This only affects sites (typically CI and dev setup) where
$wgDBerrorLog is used, as opposed to the more common
$wgDebugLogGroups by-channel configuration.
* TransactionProfiler gets its logger injected in a rather odd way,
via entrypoints (MediaWiki.php, ApiMain.php, and MaintenanceRunner)
as opposed to service wiring. This is kept as-is for now.
* In LBFactoryTest, in particular testInvalidSelectDBIndependent2,
there are cases that intentionally produce failures of which
the result is then observed. In CI we assert that dberror.log is
empty so instead of adding the missing logger fields to that
LBFactory instance, the only one set (replLogger) is removed.
The alternative is to set 'logger' now, which would naturally
cause CI failures due to unexpected entries coming through to
non-mocked error log.
Bug: T320873
Change-Id: I7ca996618e41b93f488cb5c4de82000bb36e0dd3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for running a script by file name in addition to class
name.
The following will all call the version script:
maintenance/run.php Version # by class name
maintenance/run.php maintenance/version.php # by full path
maintenance/run.php version # by plain name
The following will call SomeScript in the MyExt extension:
maintenance/run.php MediaWiki.Extension.MyExt.Maintenance.SomeScript
maintenance/run.php extensions/MyExt/maintenance/someScript.php
maintenance/run.php MyExt:SomeScript
Change-Id: I9f8057bfc9070987adc7720adf10d299e9733083
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Maintenance scripts can now be run like this:
maintenance/run.php <class>
NOTE: This introduces a new callback into Setup.php,
MW_FINAL_SETUP_CALLBACK. In contrast to MW_SETUP_CALLBACK, it is
called after extensions have been initialized.
Bug: T99268
Change-Id: Ia221f72d6b7d23df74623d60ade7fe3e5d913074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the protocol to HTTPS. Update the titles of the Wikipedia
articles mentioned in qqq.json – [[Exchangeable image file format]]
became [[Exif]] and [[Dilution of precision (GPS)]] became [[Dilution of
precision (navigation)]]. Fix the importImages.php --source-wiki-url
documentation – the private methods getFileCommentFromSourceWiki() and
getFileUserFromSourceWiki() directly append /api.php to the URL, so it
needs to include the script path. And update the broken mailing list
archive URLs (manually found the matching threads in the archives for
the respective months).
Change-Id: I1f085532ab720265acb1213f33869f759a987d92
|
|
|
|
|
|
|
|
| |
This moves the handling for the following parameters fully into the
MaintenanceRunner class:
--conf, --wiki, --globlas, --memory-limit, --server, --profiler
Change-Id: I63624ba1fcbcf446630eba1b81b2c84b1a943932
|
|
|
|
|
|
| |
All code related to the runtime environment should live in the runner.
Change-Id: I50dc30be805378b4febc57d5f5a0967afa377dfa
|
|
This is the first step toweards having a proper script runner.
Change-Id: I121ef0186b7112f12d30229293baf89c93c971b4
|