aboutsummaryrefslogtreecommitdiffstats
path: root/maintenance/includes/MaintenanceRunner.php
Commit message (Collapse)AuthorAgeFilesLines
* maintenance: Use type declaration on undocumented private functionsUmherirrender2025-03-311-2/+2
| | | | Change-Id: I2c1bc3b4e0ee782076ddaeae133672b730d345d9
* Replace a number of uses of class aliases with the real thingsJames D. Forrester2025-03-261-1/+0
| | | | | | | 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
* Remove 2-line PHPDocs that just repeat the types from the codethiemowmde2025-01-171-8/+0
| | | | | | | | | | | | | | | | 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
* Remove trivial 1-line PHPDocs that just repeat the codethiemowmde2025-01-161-3/+0
| | | | | | | | | | | | | 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
* Stats: Move StatsFactory flush into emitBufferedStatsCole White2024-12-031-1/+2
| | | | | | | | | | | | 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
* Use fake maintenance scripts in MaintenanceRunnerTest where necessaryDreamy Jazz2024-08-081-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix MaintenanceRunner test failures on WindowsBartosz Dziewoński2024-05-031-14/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Deprecate $wgCommandLineModeBartosz Dziewoński2024-01-021-6/+1
| | | | | | | | The global variable is now exactly the same as `MW_ENTRY_POINT === 'cli'`. Bug: T313841 Change-Id: I254bf4aa426e4834705be351cc9eb06d18a33f79
* Replace $wgCommandLineMode checks with MW_ENTRY_POINT in other placesBartosz Dziewoński2024-01-021-3/+1
| | | | | | | | I'm not sure if there's a good way to split this up into logical chunks. Bug: T313841 Change-Id: I3b35a2e475b5143f383d4085fbc6a0ed3bbc32b8
* Namespace remaining files under includes/deferredJames D. Forrester2023-11-221-1/+1
| | | | | Bug: T166010 Change-Id: Ibd40734b96fd2900e3ce12239d09becfb4150059
* Namespace Config-related classes under \MediaWiki\ConfigJames D. Forrester2023-09-211-1/+1
| | | | | Bug: T166010 Change-Id: I4066885a7ea071d22497abcdb3f95e73e154d08c
* maintenance: Move `shutdown()` logic to MaintenanceRunnerDerick Alangi2023-09-121-2/+62
| | | | | | | | | | | | 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
* Merge "content,maintenance: Use class-string<ClassName> in doc blocks"jenkins-bot2023-07-311-2/+5
|\
| * content,maintenance: Use class-string<ClassName> in doc blocksthiemowmde2023-07-311-2/+5
| | | | | | | | | | | | | | | | 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
* | Avoid calling overrideConfigValue() multiple timesthiemowmde2023-07-201-6/+7
|/ | | | | | | | | | 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
* MaintenanceRunner: keep track of script class explicitly.daniel2023-03-151-17/+39
| | | | | | | Reduce potential for confusion between file names and class names in MaintenanceRunner. Change-Id: I8be566925beced6ef6f1075e430d6afc38dbae6b
* MaintenanceRunner: load script file early if possibleKevin Israel2023-03-141-0/+50
| | | | | | | | | | | | | | | | | | | | 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
* Allow some maintenance scripts to be called without a LocalSettingsdaniel2023-02-161-31/+62
| | | | | | | | | | | | | | | | | | | | 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
* Merge "MaintenanceRunner: Print error if Maintenance initialization fails"jenkins-bot2023-02-121-2/+11
|\
| * MaintenanceRunner: Print error if Maintenance initialization failsKevin Israel2023-01-111-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "MaintenanceRunner: Pull some checks out of initInternal()"jenkins-bot2023-02-121-17/+1
|\|
| * MaintenanceRunner: Pull some checks out of initInternal()Kevin Israel2023-01-111-17/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
* | Add correct spaces in MaintenanceRunner.php help textAmir E. Aharoni2023-02-111-4/+4
| | | | | | | | Change-Id: I1bf2ac8888863624064dd6c8ec63d95f99aedd0d
* | MaintenanceRunner: Split up findScriptClass()Kevin Israel2023-01-291-24/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Maintenance: find file by name in maintenance dirdaniel2023-01-271-41/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | MaintenanceRunner: improve error reportingdaniel2023-01-131-18/+26
|/ | | | | | | | | | | 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
* profiler: Restore lost --profiler feature for Maintenance scriptsTimo Tijhof2023-01-051-38/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | == 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
* rdbms: Consolidate logger channels into oneTimo Tijhof2023-01-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MaintenanceRunner: find script by namedaniel2022-12-211-29/+78
| | | | | | | | | | | | | | | | | | | 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
* Introduce run.php for running maintenance scriptsdaniel2022-12-211-38/+175
| | | | | | | | | | | | | 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
* Refresh some http://*.wikipedia.org URLsLucas Werkmeister2022-11-071-1/+1
| | | | | | | | | | | | | | 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
* Runner: Handle more params in runner.daniel2022-06-131-6/+122
| | | | | | | | This moves the handling for the following parameters fully into the MaintenanceRunner class: --conf, --wiki, --globlas, --memory-limit, --server, --profiler Change-Id: I63624ba1fcbcf446630eba1b81b2c84b1a943932
* Move code from Maintenance to MaintenanceRunnerdaniel2022-05-251-1/+131
| | | | | | All code related to the runtime environment should live in the runner. Change-Id: I50dc30be805378b4febc57d5f5a0967afa377dfa
* Move code from doMaintenance.php into a runner class.daniel2022-05-211-0/+156
This is the first step toweards having a proper script runner. Change-Id: I121ef0186b7112f12d30229293baf89c93c971b4