Page MenuHomePhabricator

1.38.0-wmf.18 deployment blockers
Closed, ResolvedPublic5 Estimated Story PointsRelease

Details

Backup Train Conductor
mmodell
Release Version
1.38.0-wmf.18
Release Date
Jan 17 2022, 12:00 AM

2022 week 03 1.38-wmf.18 Changes wmf/1.38.0-wmf.18

This MediaWiki Train Deployment is scheduled for the week of Monday, January 17th:

Monday January 17thTuesday, January 18thWednesday, January 19thThursday, January 20thFriday
Backports only.Branch wmf.18 and deploy to Group 0 Wikis.Deploy wmf.18 to Group 1 Wikis.Deploy wmf.18 to all Wikis.No deployments on fridays

How this works

  • Any serious bugs affecting wmf.18 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.38.0-wmf.17
Next: 1.38.0-wmf.19

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
thcipriani changed Release Date from Jan 11 2021, 12:00 AM to Jan 11 2022, 12:00 AM.Oct 21 2021, 12:33 AM
thcipriani changed Release Date from Jan 11 2022, 12:00 AM to Jan 17 2022, 12:00 AM.Oct 21 2021, 12:43 AM
thcipriani triaged this task as Medium priority.
thcipriani updated Other Assignee, added: dduvall.
thcipriani set the point value for this task to 5.

There might be some new logs due to https://gerrit.wikimedia.org/r/751858 being merged, ignore those. I will clean them up.

Risky Patch! 🚂🔥
  • Change: https://gerrit.wikimedia.org/r/753557 Update OOUI to v0.43.0
  • Summary: OOUI v0.43.0 is an unusually big release, with an unusual amount of refactoring and cleanup. There may be bugs and accidental compatibility breaks. Looks like T299191 is the first one (and some would-be bugs were caught by unit tests in various extensions).
  • Test plan: No plan, just watch out of user interface bugs
  • Places to monitor: (the usual, I guess)
  • Revert plan: Rollback train (there's a terrible nest of dependencies if you revert the patch)
  • Affected wikis: all
  • IRC contact: MatmaRex, James_F
  • UBN Task Projects/tags: OOUI
Risky Patch! 🚂🔥
  • Change: https://gerrit.wikimedia.org/r/753557 Update OOUI to v0.43.0
  • Summary: OOUI v0.43.0 is an unusually big release, with an unusual amount of refactoring and cleanup. There may be bugs and accidental compatibility breaks. Looks like T299191 is the first one (and some would-be bugs were caught by unit tests in various extensions).

In Bawl I use this to disable a button:

document.getElementById('saveSettingsButton').attributes['aria-disabled'].value = true;

This caused the script to crash as document.getElementById('saveSettingsButton').attributes['aria-disabled'] doesn't exist anymore. I've just figured out the right way is to use Bawl.cancelSettingsButton.setDisabled(true). Considering prolific script authors like @Enterprisey insert raw HTML buttons with mw-ui-button styling (MediaWiki:Gadget-script-installer-core.js, User:Enterprisey/reply-link.js) without loading mediawiki.ui.button (which, granted, probably isn't affected by this particular issue) where they could have used OOUI would indicate to me there will be many others who play fast and loose with OOUI.

Generally gadgets and scripts, even extremely widely used ones, are not being tested on beta cluster. I'm an exception here. In case of one gadget, VisualFileChange, I tried to test it on betacommons (months ago) but I never even managed to get it to load on betacommons (beyond the source selection screen) despite my best efforts. Without VFC, Commons will descend into anarchy. It seems VFC doesn't use OOUI either, but it is an example of a gadget that's extremely important to a project but never tested on beta cluster. Twinkle on beta cluster hasn't been updated in ages either.

@Nardog I did a quick search and found https://en.wikipedia.org/wiki/User:Nardog/IPAInput-core.js and https://en.wikipedia.org/wiki/User:Ykhwong/Gadget-tabPreview.js that include "aria-disabled" and some OOUI stuff. Don't know if either will be affected though.

@Nardog I did a quick search and found https://en.wikipedia.org/wiki/User:Nardog/IPAInput-core.js and https://en.wikipedia.org/wiki/User:Ykhwong/Gadget-tabPreview.js that include "aria-disabled" and some OOUI stuff. Don't know if either will be affected though.

Both of those gadgets wouldn't be affected, as the change was only about not adding default aria-disabled="false" to widgets and TabIndexedElement.

Jdlrobson added a subscriber: Jdlrobson.

I'm off today, but https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/753990 is a blocker (it won't merge due to a CI complaint). I'll check in tomorrow when I'm back.

To the train deployer,
(to explain all the above)

Changes on T289619 introduced a regression (T299352). I replicated the error early on Friday and posted a fix (https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/753990) but a CI issue was preventing the patch from merging [1].

Selenium has been particularly flakey recently and I've been hitting npm issues. I tried again this evening but it's still not working. Perhaps @Jdforrester-WMF can help tomorrow when (if) we're both back.

An unrelated patch "Categories are modeled as a portlet" (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/754143/) was merged but it is a red herring (it fixes the issue because it prevents categories from using the hook, but it doesn't address the other consumers of that hook).

I'd feel more comfortable going into this deployment if we restored the core patch after https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/753990 finally merges and confirms the issue has gone.

In short please don't run the train unless the following 3 things have happened in this order:

See you in my morning (PST) to work this out!

[1] In hindsight, I should have cc'ed editing team on that patch, sorry about that.

@Jdlrobson Thanks for your writeup on the blockers, it's really helpful! Is there anything remaining to be done for T299352?

I am going ahead with the train after being advised T299352 is not currently a blocker.

Change 755001 had a related patch set uploaded (by Jeena Huneidi; author: Jeena Huneidi):

[operations/mediawiki-config@master] testwikis wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755001

In my opinion T299352 is still a blocker.

okay, thanks for the clarification. I've paused the deployment

Change 755001 merged by jenkins-bot:

[operations/mediawiki-config@master] testwikis wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755001

Mentioned in SAL (#wikimedia-operations) [2022-01-18T20:50:54Z] <jhuneidi@deploy1002> Started scap: testwikis to 1.38.0-wmf.18 refs T293959

Mentioned in SAL (#wikimedia-operations) [2022-01-18T21:29:26Z] <jhuneidi@deploy1002> Finished scap: testwikis to 1.38.0-wmf.18 refs T293959 (duration: 38m 31s)

Change 755027 had a related patch set uploaded (by Jeena Huneidi; author: Jeena Huneidi):

[operations/mediawiki-config@master] group0 wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755027

Change 755027 merged by jenkins-bot:

[operations/mediawiki-config@master] group0 wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755027

Mentioned in SAL (#wikimedia-operations) [2022-01-18T21:42:26Z] <jhuneidi@deploy1002> rebuilt and synchronized wikiversions files: group0 wikis to 1.38.0-wmf.18 refs T293959

Mentioned in SAL (#wikimedia-operations) [2022-01-19T13:16:51Z] <hashar> Cleaning all branch with scap clean --delete 1.38.0-wmf.13 apparently missed in previous train # T293958 T293959

Mentioned in SAL (#wikimedia-operations) [2022-01-19T13:19:17Z] <hashar> Cleaning all branch with scap clean --delete 1.38.0-wmf.12 apparently missed in previous train # T293958 T293959

Change 755479 had a related patch set uploaded (by Jeena Huneidi; author: Jeena Huneidi):

[operations/mediawiki-config@master] group1 wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755479

Change 755479 merged by jenkins-bot:

[operations/mediawiki-config@master] group1 wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755479

Mentioned in SAL (#wikimedia-operations) [2022-01-19T20:08:09Z] <jhuneidi@deploy1002> rebuilt and synchronized wikiversions files: group1 wikis to 1.38.0-wmf.18 refs T293959

Mentioned in SAL (#wikimedia-operations) [2022-01-19T20:08:59Z] <jhuneidi@deploy1002> Synchronized php: group1 wikis to 1.38.0-wmf.18 refs T293959 (duration: 00m 49s)

Change 755787 had a related patch set uploaded (by Jeena Huneidi; author: Jeena Huneidi):

[operations/mediawiki-config@master] all wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755787

Change 755787 merged by jenkins-bot:

[operations/mediawiki-config@master] all wikis to 1.38.0-wmf.18 refs T293959

https://gerrit.wikimedia.org/r/755787

Mentioned in SAL (#wikimedia-operations) [2022-01-20T20:36:10Z] <jhuneidi@deploy1002> rebuilt and synchronized wikiversions files: all wikis to 1.38.0-wmf.18 refs T293959

@matmarex we could use some clarity on the 3 blockers here. We'd much prefer to avoid rolling the train back on a Monday. I see patches on all three; should these instead be marked as blockers for this week's 1.38.0-wmf.19 (T293960) and also backported?

Yes, that might be a better way to express this. They are all issues in wmf.18 that probably should have blocked the deployment, but which were only spotted after that version rolled out everywhere. Since they have patches, we should just backport them rather than roll back.

Yes, that might be a better way to express this. They are all issues in wmf.18 that probably should have blocked the deployment, but which were only spotted after that version rolled out everywhere. Since they have patches, we should just backport them rather than roll back.

Closing this one out then