495254 - Push SUMO to 1.0.3 firedrill tag, tonight 5/28/09

Status: VERIFIED FIXED

(Infrastructure & Operations Graveyard :: WebOps: Other, task)

Description

[Laura Thomson :laura]

We need to push out 1.0.3 just to get bug 489910 into production so the nightlies don't break (see also bug 489245 which I think will be in tonight's nightly).

Tag coming later this afternoon.

Comment 1

[matthew zeier [:mrz]]

If this is causing breakage we can push off schedule and as soon as you're ready.

Comment 2

[Laura Thomson :laura]

It won't cause breakage until tonight's nightly build goes out - i.e. tomorrow, so we should be able to do it in the maintenance window.

Comment 3

[Laura Thomson :laura]

Here's the tag:
https://svn.mozilla.org/projects/sumo/tags/1.0/1.0.3_20090528/

After switching, you'll need to go in webroot/ and run
sudo ./htaccess.sh
and then dump caches as usual.

Comment 4

[Dave Miller [:justdave]]

[root@mradm02 support.mozilla.com]# svn switch https://svn.mozilla.org/projects/sumo/tags/1.0/1.0.3_20090528/
U    webroot/htaccess.dist
Updated to revision 26526.
[root@mradm02 support.mozilla.com]# cd webroot/
[root@mradm02 webroot]# sh htaccess.sh 
activating ./popups/.htaccess
activating ./tikimovies/.htaccess
activating ./files/.htaccess
activating ./temp/.htaccess
activating ./modules/.htaccess
activating ./language_files/.htaccess
activating ./templates_c/.htaccess
activating ./games/.htaccess
activating ./lang/.htaccess
activating ./components/.htaccess
activating ./pics/.htaccess
activating ./db/.htaccess
activating ./doc/.htaccess
activating ./templates/.htaccess
activating ./css/.htaccess
activating ./img/.htaccess
activating ./styles/.htaccess
activating ./backups/.htaccess
activating ./lib/fckeditor/.htaccess
activating ./lib/fckeditor_tiki/.htaccess
activating ./lib/.htaccess
activating ./js/.htaccess
activating ./.htaccess
activating ./images/.htaccess
activating ./whelp/.htaccess
activating ./bin/.htaccess

a) no templates touched, b) the only change is adding new URLs, not affecting any existing ones, so there would be nothing cached to clear.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Reopening because I (sadly) don't see this fixed on production; http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-osxkey is a 404, but should redirect to http://support.mozilla.com/en-US/kb/Firefox+Help?style_mode=inproduct (likewise with /firefox-f1)

Comment 6

[Laura Thomson :laura]

I can't verify.

I would suggest two things to check:
1.  The lines that should have changed are lines 63-65 of webroot/.htaccess.sh
They should look like
# F1/help menu detection for inproduct
RewriteRule ^1/([\-a-zA-Z]+)/([\.0-9ab]+(?:pre)?)/([\-_a-zA-Z0-9]+)/([\-a-zA-Z]+)/firefox-f1(\/)?$ /$4/kb/Firefox+Help?style_mode=inproduct [R,NE]
RewriteRule ^1/([\-a-zA-Z]+)/([\.0-9ab]+(?:pre)?)/([\-_a-zA-Z0-9]+)/([\-a-zA-Z]+)/firefox-osxkey\/$ /$4/kb/Firefox+Help?style_mode=inproduct [R,NE]

2. possible stuck git locks

Comment 7

[Dave Miller [:justdave]]

Yeah, git locks were stuck.  It was paging, and I was hoping to get one of the experts to poke at it to find out why it was stuck, but I've since given up on that and broke the lock and force-pushed, should all be up now.  (Hopefully I didn't break git in the process).

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; I looked at the bug post git-clearing, and it worked on production.

Comment 9

[David Tenser [:djst]]

Big thanks to Laura, Paul, Dave, and Stephen for the quick resolution so we can fix bug 489245 in RC1!

Tested the URLs:
http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-f1
http://support.mozilla.com/1/firefox/3.6a1pre/Darwin/en-US/firefox-osxkey

And they both work like a charm.