Last modified: 2014-10-24 17:31:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T65034, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 63034 - Caching makes it impossible to test JS changes when logged out
Caching makes it impossible to test JS changes when logged out
Status: NEW
Product: Wikimedia Labs
Classification: Unclassified
deployment-prep (beta) (Other open bugs)
unspecified
All All
: Normal major
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-24 22:23 UTC by Mark Holmquist
Modified: 2014-10-24 17:31 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mark Holmquist 2014-03-24 22:23:31 UTC
We merged https://gerrit.wikimedia.org/r/119898 on Thursday and I tested that it worked, but the old JS for the site is still cached for logged-out users so it appears at first glance to not be working. ?debug=true revealed the ?debug=truth.

Probably there should be a part of the code update job that touches any modified JS files, so the cache is invalidated. Else the cache should be explicitly invalidated on meaningful code update.

Or, at the very least, please invalidate the cache so we can actually test this feature. :)
Comment 1 Antoine "hashar" Musso (WMF) 2014-03-24 23:13:00 UTC
Restarted bits cache on pmtpa. It did not help apparently.  Maybe touch the javascript/css files ?
Comment 2 Antoine "hashar" Musso (WMF) 2014-03-24 23:17:20 UTC
ssh deployment-bastion.pmtpa.wmflabs
cd /data/project/apache/common-local/

sudo su --login --shell /bin/bash  mwdeploy

touch!

:-]
Comment 3 Antoine "hashar" Musso (WMF) 2014-03-31 09:20:29 UTC
I have no idea how the js/css resources get invalidated. Someone who knows about how bits caching works should have a look at it.
Comment 4 Greg Grossmeier 2014-05-28 16:54:29 UTC
Roan: Could you give us a tip on how to effectively/easily invalidate cached js/css on Beta Cluster when they're updated?
Comment 5 Antoine "hashar" Musso (WMF) 2014-10-24 14:53:57 UTC
Sam, any clue how we invalidate the JS/CSS cache on the bits cache when doing production deployment?   I am assuming it expires after 5 minutes automatically.
Comment 6 Krinkle 2014-10-24 17:30:43 UTC
So far this bug has failed to give any clear definition of what kind of resources this is about.

Are we talking about static resources served directly from the filesystem? E.g. files referenced directly out of skins/ or wgExtensionAssetsPath? That should only happen for for images in browsers without support for data URI embedding (or images too large to embed).

Anything loaded by ResourceLoader is naturally invalidated by proper HTTP response headers from load.php, there's no WMF-specific configuration in Varnish that makes that work.

Unversioned resources (e.g. startup module) has a cache-age of 5 minutes, and all other resources are requested via the startup with a version/timestamp in the url, and those urls respond with long-term caching (30+ days) from load.php. Varnish just consumes these max-age headers for its caching, and forwards them to the browser for client-side caching as well.

There are a few extra finetune things in Wikimedia's Varnish configuration for bits, but that should be applied to bits in Beta labs as well via puppet. If not, those manifests should be refactored to work in labs too.
Comment 7 Krinkle 2014-10-24 17:31:13 UTC
So yeah, what resources are we talking about, in what way are they not being invalidated, and how is it different from production?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links