Just a follow up to this. I don't think it will be possible to build the
javadoc and site at every time a change is pushed to the site branch.
When the site branch is reset to master after a release, the
`[maven-release-plugin] prepare for next development iteration` commit
will be on the site branch as well. In the last release, this is
https://github.com/apache/calcite/commit/8b5fae5deccfb69b9a9a571ddcdc9bef5819948b
Since the artifacts for the 1.21.0-snapshot release does not exist on
maven central, the javadoc build will fail. See
https://builds.apache.org/job/Calcite-Site/84/console
On 12/07/2019 3:01 am, Michael Mior wrote:
Francis,
I just confirmed that there were no changes in site that were not on
master and then did
git checkout site
git reset --hard origin/master
git push -f origin site
Essentially just making sure that site and master are exactly the same
after the release.
--
Michael Mior
mm...@apache.org
Le jeu. 11 juil. 2019 à 04:50, Francis Chuang
a écrit :
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
