Locally, I often get:
A LocalSettings.php file has been detected. To upgrade this installation, please run update.php instead
That one is annoying and I am not the only one:
@Niedzielski T195084#4249719
@Tarrow and @Pablo-WMDE on T200991: Document quibble learnings
Quibble does not delete LocalSettings.php since I was afraid of eventually deleting a file coming from the user. Instead we should delete it. Maybe back it up beforehand? That makes it easier to iterate over and over.
I have a dedicated directory for quibble builds, and I run quibble with
cd ~/quibble-builds && \ rm src/LocalSettings.php; \ docker run -it --rm \ --name quibble [...]
Haven't thought through it much, but maybe MediaWiki could look for a ContinuousIntegrationSettings.php file, and if that is found then LocalSettings.php is not loaded. Then Quibble could delete/modify ContinuousIntegrationSettings.php without interfering with LocalSettings
I like it. What about a separate settings file, but loaded from LocalSettings.php—then, LocalSettings.php would be very short and have a prominent warning like is often done for generated files, for example:
<?php // DO NOT EDIT THIS FILE, it is generated by quibble and will be overwritten. Your changes will be discarded... require_once( 'LocalSettings.php' );
Then, quibble can check for the "DO NOT EDIT" string. If that string is present, we can delete and regenerate LocalSettings.php. If not present, stop everything and complain that you're running quibble on production or in a development tree.
The LocalSettings.php file is generated by MediaWiki installer. Then we prepend the content of`quibble/mediawiki/local_settings.php` so that gives some mark to figure out whether an existing LocalSettings.php file has been previously generated for Quibble.
I think I will go with backing up the file before running the installer, suffixed with a timestamp. Once the install is done do a comparison and delete the backup if that is the exact same after the install has run. This way if any change has been made, a copy is kept behind.
I've been away for awhile so please excuse this comment if it doesn't make sense, but did you consider a "--deleteLocalSettings" (or similar) flag? If the flag is set, the LocalSettings.php can be deleted and database reinitialized. If not, the informational message can be shown: A LocalSettings.php file has been detected. To upgrade this installation, please run update.php instead.
I'm curious about one detail: will the existing LocalSettings.php be restored immediately after MediaWiki install, so that it can affect test runs (e.g. adding customized configuration during development)? That seems good to me.
My 2 cents about the command-line flag, it seems best to fail closed by default in case the file is accidentally present in CI. But that behavior would be modified by a flag like --skip-localsettings which does the backup-restore trick during MediaWiki install, and then runs update.php after install if the local file has been customized. Pretty much the same as the --deleteLocalSettings suggestion, just reversed.
The wisdom of this suggestion is increasingly evident :-)
I think this is the right approach, the defaults should be to do no harm to what is potentially a developer's working directory or otherwise contains valuable customizations. We're also running git clean which would have a similar, destructive effect. Let's implement a flag --destructive which is passed by default in CI.
When reading MediaWiki code, 1.38 has introduced MW_CONFIG_FILE environment variable to point to something else than LocalSettings.php:
New operator/developer features in 1.38
- EXPERIMENTAL: The environment variable MW_CONFIG_FILE can be used to specify the location of the settings file. This allows alternative settings files to be loaded depending on the environment. Settings files may be given as PHP files like the traditional LocalSettings.php file, or they may use JSON or YAML format. See https://www.mediawiki.org/wiki/Manual:YAML_settings_file_format
That comes from dcef1674a5602eba20e4a74491748d0905a14486 which was to support json.yaml format: T294750.
And maintenance/install.php can be passed --confpath to write the LocalSettings.php to some other place, I guess that could be under the log directory.
Change #1013550 had a related patch set uploaded (by Hashar; author: Hashar):
[integration/quibble@master] Remove LocalSettings.php before installing
Change #1013550 merged by jenkins-bot:
[integration/quibble@master] Remove LocalSettings.php before installing
Change #1014014 had a related patch set uploaded (by Hashar; author: Hashar):
[integration/quibble@master] release: Quibble 1.7.0
Change #1014014 merged by jenkins-bot:
[integration/quibble@master] release: Quibble 1.7.0
Mentioned in SAL (#wikimedia-releng) [2024-03-25T16:05:11Z] <hashar> Tag Quibble 1.7.0 @ 6bbe555d1006e925d5cf760da8f7c6e9374a31bc # T236222 T218647 T360443 T354141 T356247 T357070
Change #1014039 had a related patch set uploaded (by Hashar; author: Hashar):
[integration/config@master] dockerfiles: update Quibble to 1.7.0
Change #1014039 merged by jenkins-bot:
[integration/config@master] dockerfiles: update Quibble to 1.7.0
Quibble will now automatically delete an existing LocalSettings.php when it is found to contain # Quibble MediaWiki configuration\n".