incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] Super Simple Site Generation Tool
Date Thu, 29 Dec 2005 22:28:58 GMT
Geir Magnusson Jr wrote:
> Ross Gardler wrote:
>> Geir Magnusson Jr. wrote:
>>> a) edit
>>> b) render
>>> c) examine.  if not right, GOTO a)
>>> d) commit
>>> e) deploy
>>> a,c are entirely my choice of tool, so it's easy.
>>> d,e use one standard common tool.  it's easy.
>>> b needs to be simple and easy
>> The ForrestBot does b, d and e of your, i.e. the three steps that you 
>> don't list as "entirely my choice of tool".
> True, becuase it's SVN.  I suppose that to be fair, there are tools for 
> SVN now ;)  like integration into editors and nice plugins for windows 
> or something.  But I just use svn on the command line everywhere I go, 
> and I mis-thought, I guess.
>> Although e) can not be done on ASF harware until there is a way such a 
>> tool can push the content to the live servers (same problem for all 
>> tools). Of course, it can do the preparation work, such as put it in a 
>> relevant SVN server for periodic pull deployment to the servers.
> I dunno.  Here's how it works w/ the Harmony site :
> ssh -l geirm
> cd /www/
> svn update

That's exactly what the Forrestbot enables you to do (it will also 
deploy via SCP if the servers allow it).

> Now, we could probably just put a post-commit hook that does the deploy, 
> and maybe tailor it to a specific file, like DEPLOY.txt in the root or 
> such so that you just touch it, commit, and the site deploys, with the 
> added benefit that SVN will give us a log of who actually did the deploy 
> at a given time.

Sure - such a solution would be a good idea since any tool that puts the 
resulting docs in SVN will work with that solution.

>> The advantage of the forrestbot is that if you have users who edit 
>> docs but do not do b through e, then a cron job will reularly run the 
>> build and report any problems via email. This also means there is a 
>> regularly built staging area for people to independantly do c) without 
>> the need to do b).
> But I get nervous about not being able to do any QA - meaning the bits 
> that get deployed to "production" are never given even an cursory view 
> by the human that did the change.

You can still do do manual QA, the forestbot deploys to a staging site 
where it can be viewed manually. You can optionally have it deploy to 
the live server, or you can do it manually by logging into a webapp and 
clicking a deploy button (not installed on the FOrrest zone yet, but I 
run a version on a private test server at (not the staged docs and 
access to the last buiod logs).

For example, the Cocoon docs are staged at

These staging docsc are published automatically every three hours by a 
cron job (if it fails a report is sent to the dev list). They are not 
autoatically published, they are still published manually when the QA 
checks have been done.

> I may be a luddite or something, but I don't trust that kind of 
> auto-deployment.

No, I wasn't clear, it's auto-deploy of the *staged* documents for your 
steps b) and c). Hopefully the above makes it clearer.

> I don't seem to be able to grok 
> what actually changes in the doc tree for some arbitrary change. That's 
> not terrible in itself, but w/o having to commit the generated artifacts 
> myself, I can't know if things changed that I didn't expect....

Again, probably a result of my lack of clarity in the original message.

If you put the staged docs in SVN, then you get commit messages. 
However, I am happy with the commit messages from the sources, but that 
might be because of my comfort level with Forrest.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message