Hi Justin I haven't heard anything from [email protected] re, INFRA-7243, so I sent a chaser.
Separately, I raised QPID-5593 to adopt the scripts to publish jms-client-0-8. I have a patch for this which I intend to commit early this week. I pass it on to you once its is done for a review, if I may, I'd like to delete the older copies of the trunk documentation from site as soon as we have the versions published. http://qpid.apache.org/components/programming/book/index.html http://qpid.apache.org/books/trunk/Programming-In-Apache-Qpid/html/index.html It would be best if we could establish redirects from these URLs to the new location. Does anyone know if Apache allow its projects to have mod_rewrite rules? I'm happy to write the rules if someone can tell me the process I need to use to have these applied to the httpd.conf. Kind regards, Keith. On 27 January 2014 23:58, Keith W <[email protected]> wrote: > 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]
