Page MenuHomePhabricator

create instance in deployment-prep just for testing MediaWiki code not yet merged into master
Open, Needs TriagePublic

Description

A fair amount of the time, I want to test a change to a maintenance script or to export/import-related functionality in a more production-like environment, after having tested it to the degree possible on my laptop. In some cases colleagues want to test such changes which require the setup of pretty complicated extensions, that are already set up and configured in deployment-prep so that we don't have to.

Unfortunately, the process for testing on an existing instance is fairly painful, given the upstream sync that wipes out one's changes every 10 minutes, and that adding phpunit to an instance can't be done with existing packages.

We (or I) could set up a dedicated instance that would have the appropriate phpunit phar files plus a change to CommonSettings-labs including those if they are found on an instance. This instance would not be included in mediawiki cap targets so it would not receive the upstream sync automatically. A big fat warning would be added to the MOTD reminding people who use the instance to scap pull before they run anything (including copying over their changes for testing). This host would look more or less like an mwmaint instance but without any cron jobs, and of course not being in the pool to serve mediawiki requests.

This task serves as a place to start the discussion with releng and whomever else has ideas about it.

Event Timeline

This is pretty similar to the ground work we'd need for T248683: Create and run a suite of end-to-end tests for the Wikimedia environment.

Well I would love it if we could use such an instance for at least some of those things!

So... would anyone mind if I went ahead and JFDI? I probably would have to concoct some custom role but if people don't mind the extra manifest it shouldn't be too hard.

adding phpunit to an instance can't be done with existing packages

Running PhpUnit on a host that has config for actual beta databases/services sounds incredibly dangerous to me, are you sure this won't cause any issues?

I probably would have to concoct some custom role but if people don't mind the extra manifest it shouldn't be too hard.

I don't think you'd need that for the MW installation (add the role, but don't add it at Scap hiera), you'll only need that for MOTD/other warnings/etc.

adding phpunit to an instance can't be done with existing packages

Running PhpUnit on a host that has config for actual beta databases/services sounds incredibly dangerous to me, are you sure this won't cause any issues?

As long as people are forewarned not to run integration tests but only true unit tests (which by definition don't write to the db), and if they aren't sure, they better look at the specific test to see what it does.

I probably would have to concoct some custom role but if people don't mind the extra manifest it shouldn't be too hard.

I don't think you'd need that for the MW installation (add the role, but don't add it at Scap hiera), you'll only need that for MOTD/other warnings/etc.

We don't really need the instance to have a web server on there, for example. And it shouldn't be possible to pool it. The dumps instances (and boxces in prod too) are like this. But I'll have to look at the available profiles to see what makes good sense.