Spread Firefox staging server holding on to its CSS cache / not picking up /reflecting CSS changes

VERIFIED FIXED

Status

mozilla.org Graveyard
Server Operations
--
critical
VERIFIED FIXED
9 years ago
3 years ago

People

(Reporter: stephend, Assigned: oremj)

Tracking

Details

(URL)

(Reporter)

Description

9 years ago
Bug 479302 and bug 478362 should be visible on https://spreadfirefox.authstage.mozilla.com/, but for some reason, aren't:

buchanae: yeah, the css has been cached, and I can't get it cleared
buchanae: everything else makes it through
stephend: ah
stephend: oh
stephend: drupal cache, right?
buchanae: i've cleared the drupal cache
(Reporter)

Comment 1

9 years ago
Seems to be working now; Alex, any idea what fixed this?
I have no idea.  I tried clearing every cache I could reach, and I tried bypassing the NS by appending ?aslkfd to the URL.  It cleared itself somewhere around 12-1am.
Also, this has been happening every time I commit CSS changes (and we're doing a lot of those) so any ideas would be much appreciated.
(Reporter)

Updated

9 years ago
Severity: major → critical
(Reporter)

Comment 4

9 years ago
IT: do you have cycles to look at this?  We're currently experiencing issues with it, so might be a good time to look at it; thanks!

Updated

9 years ago
Assignee: server-ops → oremj
(Assignee)

Comment 5

9 years ago
Bypassing the NS by appending a random query string didn't work?
(Reporter)

Comment 6

9 years ago
(In reply to comment #5)
> Bypassing the NS by appending a random query string didn't work?

AFAIK, it still happens (again, only with CSS changes); pretty sure both Alex and I have tried the cache-override trick, but we'll be sure to test it again and report back when some CSS changes land soonish.
oremj, any ideas for this?  bypassing the NS with a random query string hasn't worked, neither had clearing the Drupal caches.
(In reply to comment #6)
> (In reply to comment #5)
> > Bypassing the NS by appending a random query string didn't work?
> 
> AFAIK, it still happens (again, only with CSS changes); pretty sure both Alex
> and I have tried the cache-override trick, but we'll be sure to test it again
> and report back when some CSS changes land soonish.

Don't forget you'll need to use the random-string on each individual CSS/JS/etc. file, not just the one page.
> Don't forget you'll need to use the random-string on each individual
> CSS/JS/etc. file, not just the one page.

ah, that did it.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
actually, can we prevent CSS from being cached on the NS for stage only?  That way we can see/QA changes immediately.  It seems to take quite a while to clear itself.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Assignee)

Comment 11

9 years ago
I've added nocache headers to *.css via apache.
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

9 years ago
Seems to be fixed for me; lots of CSS fixes landed today (thanks, Neil!), and there wasn't any downtime in picking up those fixes.

Verified.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.