Change Details

Here is what this command, as invoked on a deployment server does ([source code](https://github.com/wikimedia/operations-mediawiki-config/blob/962fb59a7b3536afce304a97093ea6e3c8df0209/scap/plugins/updateinterwikicache.py)): * Run the `mwscript extensions/WikimediaMaintenance/dumpInterwiki.php` script, and write its output to disk, overwriting what was there from Gerrit, at `/srv/mediawiki-staging/wmf-config/interwiki.php`. It then runs a basic php lint check. * Commit the change to this PHP source file as a local out-of-Gerrit commit on the deployment server. * Prompt the user for their Gerrit/LDAP username and password, to authenticate with Gerrit over HTTP. ** This is because the server uses an anonymous HTTP check out, which makes perfect sense for deployments, but not for development. Some people say they use a personal gitconfig file to str-replace the git remote from http to ssh+git, and that one can use key forwarding to avoid this authentication step. However key-forwarding is no longer acceptable in production. ** Another way is to generate a temporary app password via your personal [gerrit.wikimedia.org](https://gerrit.wikimedia.org/r/#/settings/http-password) settings, and use that instead. This however is not documented anywhere and afaik not what people would generally do. * Once authenticated, it submits the commit to Gerrit for review, and automatically self `CR+2`s the commit using a custom extension of the Git protocol that tells Gerrit to do this. * It sleeps until the user has pressed Y to indicate CI has merged the commit. * It then automatically syncs the PHP file in question. The following are most notably absent from all this: * Security best practices. * Code review, or at least seeing the diff and naturally review it. * Staging on mwdebug. As a very recent example, I doubt that if I had run this Scap command today, that I would noticed the interwiki script is seriously broken at the moment (see T247097). If I had run it, it would have irreversably corrupted new entries to the Parser Cache on all wikis. The interwiki map would have misinformed the Parser and that stuff is really had to reverse once it is out there in the database's link tables and Parser Cache. It can be reverted but it won't fix whatever has broken. I suggest we disable it as soon as possible, in favour of running it as the three separate steps that they are. 1. Run the script and copy the output to your local checkout of mediawik-config.git. (E.g. copy from ssh screen buffer, or as I do, write to a file in your home directory and then simply `scp` it to your local checkout). 2. Review the diff and commit to Gerrit, then once therer review it once more and +2. 3. Do a normal deployment (pull to deployment, pull to mwdebug, verify there, check logstash/mwdebug, sync to prod).

Here is what this command, as invoked on a deployment server does ([source code](https://github.com/wikimedia/operations-mediawiki-config/blob/962fb59a7b3536afce304a97093ea6e3c8df0209/scap/plugins/updateinterwikicache.py)): * Run the `mwscript extensions/WikimediaMaintenance/dumpInterwiki.php` script, and write its output to disk, overwriting what was there from Gerrit, at `/srv/mediawiki-staging/wmf-config/interwiki.php`. It then runs a basic php lint check. * Commit the change to this PHP source file as a local out-of-Gerrit commit on the deployment server. * Prompt the user for their Gerrit/LDAP username and password, to authenticate with Gerrit over HTTP. ** This is because the server uses an anonymous HTTP check out, which makes perfect sense for deployments, but not for development. Some people say they use a personal gitconfig file to str-replace the git remote from http to ssh+git, and that one can use key forwarding to avoid this authentication step. However key-forwarding is no longer acceptable in production. ** Another way is to generate a temporary app password via your personal [gerrit.wikimedia.org](https://gerrit.wikimedia.org/r/#/settings/http-password) settings, and use that instead. This however is not documented anywhere and afaik not what people would generally do. * Once authenticated, it submits the commit to Gerrit for review, and automatically self `CR+2`s the commit using a custom extension of the Git protocol that tells Gerrit to do this. * It sleeps until the user has pressed Y to indicate CI has merged the commit. * It then automatically syncs the PHP file in question. The following are most notably absent from all this: * Security best practices. * Code review, or at least seeing the diff and naturally review it. * Staging on mwdebug. As a very recent example, I doubt that if I had run this Scap command today, that I would noticed the interwiki script is seriously broken at the moment (see T247097). If I had run it, it would have irreversably corrupted new entries to the Parser Cache on all wikis. The interwiki map would have misinformed the Parser and that stuff is really had to reverse once it is out there in the database's link tables and Parser Cache. It can be reverted but it won't fix whatever has broken. I suggest we disable it as soon as possible, in favour of running it as the three separate steps that they are. 1. Run the script and copy the output to your local checkout of mediawik-config.git. (E.g. copy from ssh screen buffer, or as I do, write to a file in your home directory and then simply `scp` it to your local checkout). 2. Commit the diff, submit to Gerrit, then once there review it once more and +2. 3. Perform a normal deployment (pull on deployment host, pull on mwdebug, verify on-wiki, check logstash, sync to prod).

Here is what this command, as invoked on a deployment server does ([source code](https://github.com/wikimedia/operations-mediawiki-config/blob/962fb59a7b3536afce304a97093ea6e3c8df0209/scap/plugins/updateinterwikicache.py)): * Run the `mwscript extensions/WikimediaMaintenance/dumpInterwiki.php` script, and write its output to disk, overwriting what was there from Gerrit, at `/srv/mediawiki-staging/wmf-config/interwiki.php`. It then runs a basic php lint check. * Commit the change to this PHP source file as a local out-of-Gerrit commit on the deployment server. * Prompt the user for their Gerrit/LDAP username and password, to authenticate with Gerrit over HTTP. ** This is because the server uses an anonymous HTTP check out, which makes perfect sense for deployments, but not for development. Some people say they use a personal gitconfig file to str-replace the git remote from http to ssh+git, and that one can use key forwarding to avoid this authentication step. However key-forwarding is no longer acceptable in production. ** Another way is to generate a temporary app password via your personal [gerrit.wikimedia.org](https://gerrit.wikimedia.org/r/#/settings/http-password) settings, and use that instead. This however is not documented anywhere and afaik not what people would generally do. * Once authenticated, it submits the commit to Gerrit for review, and automatically self `CR+2`s the commit using a custom extension of the Git protocol that tells Gerrit to do this. * It sleeps until the user has pressed Y to indicate CI has merged the commit. * It then automatically syncs the PHP file in question. The following are most notably absent from all this: * Security best practices. * Code review, or at least seeing the diff and naturally review it. * Staging on mwdebug. As a very recent example, I doubt that if I had run this Scap command today, that I would noticed the interwiki script is seriously broken at the moment (see T247097). If I had run it, it would have irreversably corrupted new entries to the Parser Cache on all wikis. The interwiki map would have misinformed the Parser and that stuff is really had to reverse once it is out there in the database's link tables and Parser Cache. It can be reverted but it won't fix whatever has broken. I suggest we disable it as soon as possible, in favour of running it as the three separate steps that they are. 1. Run the script and copy the output to your local checkout of mediawik-config.git. (E.g. copy from ssh screen buffer, or as I do, write to a file in your home directory and then simply `scp` it to your local checkout). 2. ReviewCommit the diff and com, submit to Gerrit, then once therer review it once more and +2. 3. DoPerform a normal deployment (pull toon deploymentt host, pull toon mwdebug, verify thereon-wiki, check logstash/mwdebug, sync to prod).