I plan to finalize this over the next few days. I think the naive
solution of building the javadocs on each push is the best solution so far.
I've considered Vladimir's solution of using the Jenkins workspace to
store previous builds, but I've had issues where builds fail if the
previous build failed and the workspace was dirty while building
releases. Due to that, I am more inclined to start with a clean
workspace for every build until we get a more performant solution in place.
Francis
On 11/07/2019 9:33 am, Stamatis Zampetakis wrote:
Thanks for working on this Francis, great progress!
As far as I can tell there is nothing really blocking to start using the
automated builds.
Since at the moment we don't really have a good solution for triggering the
javadoc build on tag creation I would suggest to go on with the naive
solution (i.e., build on every push).
The site is not updated too often so I guess it is acceptable to have a
long build pipeline once in a while.
We can create a JIRA for improving the time and leave it open till we find
a better solution on this (Gradle, Jenkins, or other trick).
Best,
Stamatis
On Fri, Jul 5, 2019 at 9:16 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
Francis>javadocs takes around 20 minutes to build
I did not thought it takes so much time.
"tag" trigger for javadocs is clever, and I just thought we might want to
be able to update the wording on the site javadoc without releasing
Calcite.
That is why I suggested to build javadoc for all site pushes.
I wonder if the job can reuse the workspace.
I guess it can see the results of the previous builds, so it could just
reuse the javadocs if they are the same.
Here's what I have for Avatica:
$ time ./gradlew javadoc
real 0m33.714s
user 0m5.499s
sys 0m0.399s
$ time ./gradlew javadoc
real 0m2.916s
user 0m2.646s
sys 0m0.208s
It skips the processing provided no modifications to the javadocs was made.
Vladimir
