I meant to ask this in my previous email, but forgot.
Michael, when you were RM for the last Calcite release, what was the git
command used to even the master and site branches when the release was
finalized?
I'd like to have that documented as part of this change as well.
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
