Page MenuHomePhabricator

No /static/1.26wmf7 tree -- mediawiki.org missing "Powered by MediaWiki" logo and ResourceLoader ?debug=1 mode broken
Closed, ResolvedPublic

Description

When I visit https://www.mediawiki.org , the "Powered by MediaWiki" logo at the bottom is missing and the browser console shows

"NetworkError: 404 Not Found - https://www.mediawiki.org/static/1.26wmf7/resources/assets/poweredby_mediawiki_132x47.png"

If I visit a page with ?debug=1 I get a ton of 404s for other content in /static/1.26wmf7
I have the same problems on testwiki, another group 0 wiki.

On tin, /srv/mediawiki$ ls docroot/mediawiki/static/ contains earlier static trees up to 1.26wmf6, but no 1.26wmf7

Event Timeline

Spage assigned this task to mmodell.
Spage raised the priority of this task from to High.
Spage updated the task description. (Show Details)
Spage added subscribers: Spage, greg.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 21 2015, 10:23 AM

Ok I just noticed something else that looks out of order:

/srv/mediawiki-staging$ ls docroot/bits
404.html  503.html  apple-touch  favicon  index.html  pybal-test-file  static  static-1.26wmf1	static-1.26wmf2  static-1.26wmf3  static-1.26wmf4  static-current  static-master  w  WikipediaMobileFirefoxOS

the bits symlinks stop at wmf4. I'm still investigating, not sure what changed, I've been using scripts to automate all the fiddly steps so it should be all set up correctly.

I wonder if this is related to "bits-related changes" mentioned in operations/mediawiki-config log, and/or T95448: Move bits traffic to text/mobile clusters

... the bits symlinks stop at wmf4.

Yes, the creation of static content doesn't match the Train deploys instructions any more.

mmodell lowered the priority of this task from High to Medium.May 21 2015, 12:07 PM

https://gerrit.wikimedia.org/r/#/c/212535/ is the result of re-running checkoutMediawiki for 1.26wmf7, so somehow that change got reverted during my earlier deploy. It doesn't help that the deployment process explicitly does git reset --hard - it's easy to accidentally throw away commits.

But a few things remain confusing to me:

  1. @Spage mentions that docroot/mediawiki/static was missing the latest branch. Well, none of the deployment steps create a symlink there - is it created by scap?
  2. Apparently the layout of docroot/bits and w/static/ changed recently, but there are remnants of the old layout laying around, and I don't think the change was well publicized. Inconsistencies:
    • docroot/bits/static-current/* point to /srv/mediawiki/php-1.26wmf3/*
    • docroot/bits/static/current/* also point to /srv/mediawiki/php-1.26wmf3/*
    • w/static/current/* correctly updated to point to /srv/mediawiki/php-1.26wmf7/*

I'm not entirely sure what symlinks are currently relevant, perhaps the bits/static[-/]current/* symlinks are obsolete and should be removed? There are quite a few other outdated symlinks scattered around. I need to investigate further to fully understand this mess.

So the missing wmf7 symlink was probably my fault, and thanks to @Spage for catching it before it got to be a big problem. I'm keeping this task open while I look into the rest of the symlink mess a bit further.

Spage added a subscriber: ori.May 21 2015, 7:21 PM

@ori might know about the status and intent of the static cleanup.
I updated https://wikitech.wikimedia.org/wiki/Bits.wikimedia.org but my understanding is incomplete.

https://gerrit.wikimedia.org/r/#/c/212753/ adds a unit test to verify that the requisite branch symlinks exist.

I think the unit test should be adequate to prevent this happening again, though I couldn't fully validate the symlinks in a unit test because the disk layout is different on jenkins slaves than it is on tin. Really a test in scap would be more ideal.

hashar raised the priority of this task from Medium to High.May 29 2015, 4:27 PM
hashar moved this task from INBOX to In-progress on the Release-Engineering-Team board.
mmodell closed this task as Resolved.May 30 2015, 10:01 AM