directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: [site] building and deploying (part I)
Date Sun, 09 Jan 2005 21:07:07 GMT
Brett Porter wrote:

> 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?)

Funny I asked a similar question myself so we don't have to keep this in 
my home directory.  It can bet to be a pita figuring out within whose 
home dir the site staging area is kept.  Noel recommended I use my home 
directory for now until this place is determined.  I'd love to set this 
up from day 1 if I don't have to move things around.

>
>> # 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).
>
Yeah this was old stuff I still have hanging around.  Should i just blow 
it away?

>>
>> # 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.

Right, my bad I just cut and pasted my entire build.properties file into 
the email.

>
>>
>> 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.

Nice this would be most excellent.  That way I don't have to make a 
bogus cgi to rsync and protect it with a .htaccess entry.

>
> 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?

Excellent suggestions Brett.  If this publish feature was there today 
I'd be using it.  What's the effort involved in knocking this stuff 
out?  Meaning this is not possible within the near future but something 
that we can use down the road right?

Alex




Mime
View raw message