directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [site] building and deploying (part I)
Date Sun, 09 Jan 2005 19:45:41 GMT
Alex Karasulu wrote:

> I asked infra peeps if this was cool and they're on board with 
> recoving from the staging areas as opposed to CVS if something goes 
> wrong.  This btw is the main reason for having generated sitedocs 
> checked into CVS.  Note CVS is crawling now with all the empty 
> directories in there from moves and renames.  

Given this and the problems with CVS, is it worth seeing if they could 
setup this up as policy, to the extent that maybe 
/www-stage/www.incubator.apache.org/directory (or similar) could be used 
so they have one tree to rsync when they recover? (Noel - is this worth 
proposing to infrastructure?)

> # Put your username here
> maven.username=akarasulu
> maven.remote.group=apcvs

These are the ones used for site:deploy. It is still on the old 
mechanism where it forks an ssh process, so a working ssh must be in the 
path, able to connect to www.apache.org without a password (ie, have an 
agent running).

>
> # User must specify:
> maven.repo.apachecvs.username=akarasulu
>
> # Repository to deploy snapshots
> maven.repo.apachecvs=scp://cvs.apache.org
> maven.repo.apachecvs.directory=/www/cvs.apache.org/repository
> maven.repo.apachecvs.group=apcvs
> maven.repo.apachecvs.privatekey=${user.home}/.ssh/id_rsa

This is for deploying snapshots, as you've stated, but not required for 
the site.

>
> o how to kick off rsync for deploying staging area
>
> BTW looking for someone interested in writing CGI so we can put a 
> button on resources page to kick off rsync on the staging area.  
> Anyone interested in helping out?

Is that the best place? If infra@ are looking at this as a way for 
several projects to do this, maybe support in Maven would be of 
assistance to several projects.

Changes I'd make:
- site:deploy could include an optional clean step that we'd use, so it 
would publish to stage after first removing the whole subtree (an rsync 
version of this could also be developed)
- site:publish would ssh to the server and rsync stage to /www.

I'd probably use rsync -avz --delete to make sure it didn't accumulate 
crud, but there are two concerns with that:
- it'll delete anything that was pushed there manually
- I've sometimes seen mail archives stored in there - deleting these 
would probably be bad :)

presumably this is still a bad thing in terms of recovery from staging, 
though I imagine the latter are recovered from backup in a failure.

Thoughts?

Cheers,
Brett


Mime
View raw message