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 minotaur.apache.org
cd /www/incubator.apache.org/harmony/
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
http://cms.wkwyw.net:8080/forrestbot-trunk/ (not the staged docs and
access to the last buiod logs).
For example, the Cocoon docs are staged at
http://forrest.zones.apache.org/ft/build/cocoon-docs/2.1/index.html
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.
Ross
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
