We currently do it for the trunk build:

<target name="hudson-test-trunk" depends="docs,tar,findbugs"/>

but not for pull request or patch QA:

<target name="qa-test-pullrequest" depends="findbugs.check,forrest.check">

"forrest.check" only checks if the forrest.home variable is defined.

Is that enough that we run it as part of the trunk build?


> On 01 Dec 2016, at 01:04, Benjamin Reed <br...@apache.org> wrote:
> we could also build the doc as part of the tests.
> On Wed, Nov 30, 2016 at 3:26 PM, Flavio Junqueira <f...@apache.org> wrote:
>> As part of the release process, we only copy the documentation, see it here:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease 
>> <https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToRelease>
>> I think the reason we have gone this way is to avoid issues compiling the 
>> documentation at the time that we are preparing a release candidate or after 
>> voting on a release candidate. We could for sure build the documentation 
>> right before generating the first rc for a release and create blocker jiras 
>> in the case there is any issue.
>> -Flavio
>>> On 30 Nov 2016, at 23:12, Benjamin Reed <br...@apache.org> wrote:
>>> yeah, that's a deeper question. pat or flavio can correct me on this,
>>> but i think the reason we check it in is so that the website's "trunk"
>>> documentation will work. now that we moved to git, i don't thing it
>>> works though... i also would just like to only build it when we do
>>> releases.
>>> On Wed, Nov 30, 2016 at 2:24 PM, Jordan Zimmerman
>>> <jor...@jordanzimmerman.com> wrote:
>>>> I wondered about that myself. Why bother building the docs? Isn’t that 
>>>> only needed for packaging/deployment? It ends up making PRs ugly because 
>>>> you have all the unnecessary docs in the diff.
>>>> -Jordan
>>>>> On Nov 30, 2016, at 11:23 PM, Benjamin Reed <br...@apache.org> wrote:
>>>>> when we commit pull requests with doc changes, i think we should
>>>>> commit the generated doc as a separate commit. what do you all think?
>>>>> i would like to do that to keep the change from the contributors
>>>>> pristine :) and i think it simplifies things a bit.
>>>>> ben

Reply via email to