In the past, the Javadocs were only ever built right after finalizing a
release. So, in general, the javadocs do not reflect snapshot versions.
Can Julian confirm if the javadocs must be for the latest final release?
I will ask the Jenkins list to see if there are any tips for getting the
javadocs to built on a new tag for a final release. I did ask a question
regarding docker hanging (which is now fixed due to upgrades to docker
on all jenkins nodes last week), but received no response. Hopefully,
better luck this time.
On 14/07/2019 10:49 pm, Stamatis Zampetakis wrote:
From a quick look it seems that the build fails because of the following:
Could not find artifact
org.apache.calcite:calcite-core:jar:tests:1.21.0-SNAPSHOT in
apache.snapshots (https://repository.apache.org/snapshots) -> [Help 1]
So apparently the Apache Nexus repository (
https://repository.apache.org/snapshots) does not have the 1.21.0-SNAPSHOT
so perhaps we just have to push SNAPSHOT artifacts at a more regular basis.
On Sun, Jul 14, 2019 at 8:56 AM Francis Chuang <francischu...@apache.org>
wrote:
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
<francischu...@apache.org> 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
