Hi Justin The new CHECKOUT_DIR= arg seems to work okay. Thank you.
I have raised https://issues.apache.org/jira/browse/INFRA-7243 to have a buildbot job created for quid trunk documentation. I've initially requested that the job is created without the commit step so that its logs and output can be manually reviewed. cheers, Keith. On 23 January 2014 11:02, Justin Ross <[email protected]> wrote: > On Fri, Jan 17, 2014 at 7:45 AM, Justin Ross <[email protected]> wrote: >> On Fri, Jan 17, 2014 at 5:46 AM, Keith W <[email protected]> wrote: >>> 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. > > As of revision 1560426, you should be able run against a checkout: > > % svn update /some/checkout > % make clean [*] > % make gen-release RELEASE=trunk CHECKOUT_DIR=/some/checkout > > [*] Something I haven't mentioned before: you'll want to call make > clean before make gen-* because the gen-* scripts continue to use a > shared work dir. > >>> 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. > > It strikes me now that it will be pretty easy to add to the list of > books we want to generate and simply keep going if we can't find a > book we were expecting. That way the scripts should continue to work > against old versions. > > Justin --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
