On Fri, Jan 17, 2014 at 5:46 AM, Keith W <[email protected]> wrote: > Hi Justin > > I tested your extensions to site's make gen-release (which you > committed at rev 1556392) on an Ubuntu 12 box (like Apache's > buildbots) with the dependencies described in the README and > encountered no difficulties. The site trunk documentation renders > correctly.
That's a nice surprise! > I have a couple of remaining questions: > > 1. For buildbot integration we will need a mechanism for buildbot to > determine if there is work to be done (i.e. a test before it invokes > make gen-release RELEASE=trunk && make render). > Most CI systems I have seen use the result of an 'svn update' and only > go on to call the later build steps if there were changes, but as the > gen-release target currently takes responsibility for the svn > operation, this approach won't fit. > > At the moment I think the trigger will need to use a command such as > 'svn info http://svn.apache.org/repos/asf/qpid/trunk/qpid > http://svn.apache.org/repos/asf/qpid/proton/trunk' and trigger the > build only if the reported revision has increased since the previous > buildbot invocation. Did you have any thoughts? The solution you suggest makes sense to me. However, it doesn't seem all that difficult to change the scripts to work against a checkout, either, so I will attempt that. > 2. scripts/gen-release-books hardcodes a list of books. The list of > books we will want to > publish will vary over time (for instance I expect we will have a book > for the JMS AMQP 1.0 client). Is there a way the scripts can change > to accommodate this requirement? Presumably, the scripts need to > remain compatible with previous releases in order to be able to > republish documentation from older releases. That's a good point. When I initially developed the scripts, I wasn't anticipating a lot of regeneration. I'll have to make them less rigid. Justin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
