Closed Bug 542554 Opened 14 years ago Closed 14 years ago

getfirebug.com is auto-updating from trunk

Categories

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

Product:
Infrastructure & Operations Graveyard
Component:
WebOps: Other
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: neilio, Assigned: aravind)

Details

getfirebug.com is auto-updating from svn - projects/getfirebug.com/trunk. This should be switched back to syncing to stage ASAP.
What does that mean?  "switched back to syncing to stage" ?

Was the auto svn up in stage turned off?

Was prod set to auto svn up?

Should that svn up be pointing to something else or be turned off completely?
Assignee: server-ops → aravind
Originally, trunk auto-synced to getfirebug.stage.mozilla.com. After the site launch last night, it's somehow syncing to production, which isn't great. I would like it switched back to syncing to stage.
Switched off the auto svn ups in production.

Stage is still updating to the HEAD.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
what I'd like to have is svn to auto-update from the production tag again.

This may require a merge from trunk to tags/production again.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Any updates here, guys? I have a bunch of priority fixes to push and need to get some kind of syncing mechanism set up to enable this.
also, this is critical as developers are unable to check in new unittests for our test system which relies on the contents of getfirebug.com/tests updating.
I will get this going sometime today.
awesome, thanks aravind.

I think we'll need to make sure everything from trunk is migrated into the tags/production directory. I've already made a backup of what's in there now and suspect there may be some merging to be done after the fact to get things into the right state. I'll coordinate with neil to figure that out.
I started looking into this and it looks like at some point we have the getfirebug.com updating automatically from the production tag.  But the current site is deployed against the trunk.

I did a brief diff against the two and it looks like there are a ton of differences between the two.  Here is what I have.

[root@mradm02 getfirebug.com]# svn info
Path: .
URL: http://svn.mozilla.org/projects/getfirebug.com/trunk
Repository Root: http://svn.mozilla.org
Repository UUID: 4eb1ac78-321c-0410-a911-ec516a8615a5
Revision: 61287
Node Kind: directory
Schedule: normal
Last Changed Author: nlee@mozilla.com
Last Changed Rev: 61283
Last Changed Date: 2010-01-27 09:49:23 -0800 (Wed, 27 Jan 2010)


And this is the site that used to be auto-updated from tags/production.
[root@mradm02 getfirebug.com-tag]# svn info
Path: .
URL: http://svn.mozilla.org/projects/getfirebug.com/tags/production
Repository Root: http://svn.mozilla.org
Repository UUID: 4eb1ac78-321c-0410-a911-ec516a8615a5
Revision: 61239
Node Kind: directory
Schedule: normal
Last Changed Author: odvarko@gmail.com
Last Changed Rev: 61161
Last Changed Date: 2010-01-26 01:54:26 -0800 (Tue, 26 Jan 2010)

[root@mradm02 getfirebug.com-tag]# 


How do you want me to proceed here?  Can I just blow away the current trunk site and update it from tags/production?
From https://bugzilla.mozilla.org/show_bug.cgi?id=538320#c1
"...there are a number of directories we need to watch out for and not touch.
blog/
lite/
tests/
releases/"

In addition, there's a developer subdirectory which needs to stay as it is (under tags/production).

Those live under tags/production and still need to exist as they are. I've made a backup of them in tags/production-1.5 in case anything happens to them.

I'd recommend moving trunk to tags/production and re-enabling updates from that. This was how I wanted to do the deployment in the first place, but here we are.
also, please let me know if this is something you'd like me to do. Not sure what order will work best, if we should sync these subdirectories from production to trunk or ... ? Let me know.
The other projects work like this.

Folks either just ask us to pull things directly from trunk or they keep moving (updating) the production tag and we pull from that.  It is in general not wise to trust sysadmins to put websites together (like watching certain directories are not touched etc) when we do it for some emergency at 4:00 AM or when we are in a rush to get something else done.

So yeah, I would like you to adjust the repo and give me a tag (or trunk) to pull from that will just (auto)update the site as needed.
yeah, agreed. I don't want anybody to have figure out what to push at 4am. I know I'd make a mess of it in that state. :)

We were updating from tags/production before and I think that's the preferred directory. That way we can continue to use trunk for staging. That said, Neil just copied production's subdirectories into trunk to sync up. We'll need to move the contents of trunk into tags/production to make this work.

Neil, back me up here. I think what I'm saying is true, but would like a second opinion.

Aravind, if Neil verifies and we're able to merge trunk into tags/production, can you just set the site to pull from that as it was doing before? If so, you should wait for Neil's go-ahead once he's merged the directories.

thanks!
I think that's right - all of the missing directories from the tags/production are now in trunk, so it should be safe to copy trunk over to tags/production and turn syncing to prodution back on. How many more times can I type production?

Arvind: r61662 is the fully-synced up revision.
(production)

OK, let's do that copy (from trunk to tags/production) and advise Mr. Gottipati when complete.
aravind: we should be good to go. I've made a new copy of trunk in tags/production at revision 61685. Pulling form there should get our new changes.
I haven't pushed this live yet, but here are the differences I see.

[root@mradm02 www]# diff --brief -r getfirebug.com getfirebug.com-production | grep -v svn | less
Only in getfirebug.com: blog
Only in getfirebug.com-production: chromebug
Only in getfirebug.com/css: ie.css
Only in getfirebug.com/css: master.css
Only in getfirebug.com/css: reset.css
Only in getfirebug.com/css: screen.css
Files getfirebug.com/css.php and getfirebug.com-production/css.php differ
Only in getfirebug.com-production: developer
Only in getfirebug.com-production: doc
Only in getfirebug.com-production: firebug
Files getfirebug.com/.htaccess and getfirebug.com-production/.htaccess differ
Files getfirebug.com/includes/header.php and getfirebug.com-production/includes/header.php differ
Only in getfirebug.com-production: lite
Files getfirebug.com/perch/config/config.php and getfirebug.com-production/perch/config/config.php differ
Only in getfirebug.com-production/releases/chromebug: chromebug-1.6.0a4.xpi
Files getfirebug.com/releases/chromebug/update.rdf and getfirebug.com-production/releases/chromebug/update.rdf differ
Only in getfirebug.com-production/releases/firebug/1.6X: firebug-1.6X.0a4.xpi
Files getfirebug.com/releases/firebug/1.6X/update.rdf and getfirebug.com-production/releases/firebug/1.6X/update.rdf differ
Only in getfirebug.com/releases/lite/beta: ChangeLog
Only in getfirebug.com-production/releases/lite/beta: changelog.txt
Only in getfirebug.com/releases/lite/beta: errorIcon.png
Only in getfirebug.com/releases/lite/beta: firebug.gif
Only in getfirebug.com-production/releases/lite/beta: firebug.jgz
Only in getfirebug.com-production/releases/lite/beta: firebug.js
Only in getfirebug.com/releases/lite/beta: firebug-lite-compressed.js
Only in getfirebug.com/releases/lite/beta: firebug-lite.css
Only in getfirebug.com/releases/lite/beta: firebug-lite.js
Only in getfirebug.com/releases/lite/beta: firebug_logo.png
Only in getfirebug.com-production/releases/lite/beta: firebug.tar.tgz
Only in getfirebug.com-production/releases/lite/beta: firebug.uncompressed.js
Only in getfirebug.com-production/releases/lite/beta: .htaccess
Only in getfirebug.com-production/releases/lite/beta: index.html
Only in getfirebug.com/releases/lite/beta: infoIcon.png
Only in getfirebug.com/releases/lite/beta: jsmin.py
Only in getfirebug.com/releases/lite/beta: jsmin.pyc
Only in getfirebug.com/releases/lite/beta: lib.js
Only in getfirebug.com/releases/lite/beta: minifier.py
Only in getfirebug.com/releases/lite/beta: minify
Only in getfirebug.com/releases/lite/beta: progress.gif
Only in getfirebug.com-production/releases/lite/beta: skin
Only in getfirebug.com/releases/lite/beta: spacer.gif
Only in getfirebug.com-production/releases/lite/beta: template .htaccess
Only in getfirebug.com/releases/lite/beta: tree_close.gif
Only in getfirebug.com/releases/lite/beta: tree_open.gif
Only in getfirebug.com/releases/lite/beta: warningIcon.png
Only in getfirebug.com-production: styles
Only in getfirebug.com-production/tests/issues: 2710
Only in getfirebug.com-production: updateInfo
Only in getfirebug.com: wiki
[root@mradm02 www]#

Is this what you expect?
no. I get:

diff -r -x \.svn trunk tags/production                                         Only in trunk: .DS_Store
Only in trunk/images: .DS_Store

under projects/getfirebug.com in my local copy. This is after clobbering tags/production and repulling.

I did an svn copy https://.../trunk https://.../tags/production to arrive in this state after removing tags/production.

There shouldn't be any differences outside of the .svn subdirs.
also, presumably the .DS_Store files are not under version control and only exist under my working copy. I can repull if necessary, but because my changes were all server-side, there shouldn't be a problem.
Just a note here. For the Firebug Lite, the content in
getfirebug.com/releases/lite/* is outdated, and should be replace with the
contents at: /projects/getfirebug.com/tags/production/releases/lite/*

But this is a minor issue. Once synchronized, I can delete/update files myself.
It seems that the synchronization is working fine again.

Thank you all!
automatic updates to tags/production enabled.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.