Page MenuHomePhabricator

1.37.0-wmf.14 deployment blockers
Closed, ResolvedPublicRelease

Details

Backup Train Conductor
brennen
Release Version
1.37.0-wmf.14
Release Date
Jul 12 2021, 12:00 AM

2021 week 28 1.37-wmf.14 Changes wmf/1.37.0-wmf.14

This MediaWiki Train Deployment is scheduled for the week of Monday, July 12th:

Monday July 12thTuesday, July 13thWednesday, July 14thThursday, July 15thFriday
Backports only.Branch wmf.14 and deploy to Group 0 Wikis.Deploy wmf.14 to Group 1 Wikis.Deploy wmf.14 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.14 should be added as subtasks beneath this one.
  • Any open subtask(s) block the train from moving forward. This means no further deployments until the blockers are resolved.
  • If something is serious enough to warrant a rollback then you should bring it to the attention of deployers on the #wikimedia-operations IRC channel.
  • If you have a risky change in this week's train add a comment to this task using the Risky patch template
  • For more info about deployment blockers, see Holding the train.

Related Links

Other Deployments

Previous: 1.37.0-wmf.13
Next: 1.37.0-wmf.15

Event Timeline

thcipriani triaged this task as Medium priority.
thcipriani updated Other Assignee, added: LarsWirzenius.
thcipriani updated Other Assignee, added: brennen; removed: LarsWirzenius.
thcipriani added a subscriber: brennen.

Note T285820: Deployment server is likely to be switched to deploy2002 prior to train on 2021-07-14.

Risky Patch! 🚂🔥

Revert plan: Revert the patch

I think the most likely issue is a typo or copy/paste error (inverted logic, wrong token name, missing parameter). The fix should be fairly obvious from the diff, so perhaps the first thing to try would be to simply fix the issue manually rather than revert the patch.

Note: During sync, you're likely to see something like:

17:04:22 ['/usr/bin/scap', 'pull', '--no-update-l10n', '--no-php-restart', '--include', 'php-1.37.0-wmf.12', '--include', 'php-1.37.0-wmf.12/includes', '--include', 'php-1.37.0-wmf.12/includes/user', '--include', 'php-1.37.0-wmf.12/includes/user/UserOptionsManager.php', 'mw1319.eqiad.wmnet', 'mw1366.eqiad.wmnet', 'mw2300.codfw.wmnet', 'mw2289.codfw.wmnet', 'mw2254.codfw.wmnet', 'mw1269.eqiad.wmnet', 'mw1285.eqiad.wmnet', 'mw1313.eqiad.wmnet'] on mw2383.codfw.wmnet returned [255]: ssh: connect to host mw2383.codfw.wmnet port 22: Connection timed out
sync-apaches: 100% (ok: 342; fail: 1; left: 0)
17:04:22 1 apaches had sync errors

...

17:05:01 /usr/bin/sudo -u root -- /usr/local/sbin/check-and-restart-php php7.2-fpm 100 on mw2383.codfw.wmnet returned [255]: ssh: connect to host mw2383.codfw.wmnet port 22: Connection timed out

17:05:01 1 hosts had failures restarting php-fpm

As mw2383 is misbehaving - see T286463.

Late (US) Wednesday afternoon status: After work on T286521, we've rolled forward to group1. Generally, things seem quiet, although T286521 continues to crop up.

Possible blocker: T286679: Some interface messages are in Welsh when British English is selected as the interface language isn’t a very serious issue, but may annoy a number of English Wikipedia users if it reaches group2. (It’s not yet clear how many messages would be affected, and I also don’t know how many people actually have their user interface set to en-gb.)

T286679 is a problem but I don't think it should be a train blocker, its impact is really limited.

T286679 is a problem but I don't think it should be a train blocker, its impact is really limited.

Thanks @Ladsgroup