The SWAT workflow is to test on mwdebug1002 first before moving to the rest of production. For mwscript scripts, this is impossible, since it doesn't have the Zend extensions.
TODO: Make a note in the SWAT and (whatever relevant) maintenance script docs to use terbium as the test machine for maintenance scripts (where they run anyway, they don't run on mwdebug*/mw* hosts).
From T146286: mwscript on jessie mediawiki fails , we had the puppet class ::mediawiki::packages::php5 added to role::deployment::mediawiki. The reason we needed them is that mwscript is still hardcoded to use php5 T146285.
If ones want to test a change via mwscript, I think the easiest is to deploy the staged change on one of the work server (eg: on terbium run scap pull). And run the script there with the new code.
The production application servers do not have those packages installed, so I would rather not apply them on the mwdebug hosts.
If we don't want to install the packages here, we should just clarify the SWAT process such that there is no testing step for maintenance script-only deploys. terbium is where those scripts normally run anyway, so there's not really a separate test step without mwdebug1002.
If we clarify the docs, I don't object to declining this.
To which entry does that comment relate? To Matt's proposal to clarify the SWAT process?
Option 2 (the proposal of clarifying the testing/swat process and not installing these packages on mwdebug*).
That means you can only use mwrepl and not mwscript eval.php on mdebug1002, see T150912.
Both T150912 and T153316 are attempts to use mwdebug1001 / mwdebug1002 as either a deployment (eg tin) or maintenance server (eg terbium). Both roles have mediawiki::packages::php5 which is the one one would need.
Lets follow up on T150912. A workaround is to ::mediawiki::packages::php5, the ultimate fix is to remove 'php5' from mwscript T146285