Last modified: 2014-10-24 17:31:13 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. :)
Restarted bits cache on pmtpa. It did not help apparently. Maybe touch the javascript/css files ?
ssh deployment-bastion.pmtpa.wmflabs cd /data/project/apache/common-local/ sudo su --login --shell /bin/bash mwdeploy touch! :-]
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.
Roan: Could you give us a tip on how to effectively/easily invalidate cached js/css on Beta Cluster when they're updated?
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.
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.
So yeah, what resources are we talking about, in what way are they not being invalidated, and how is it different from production?