>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 <[email protected]> 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 > > [email protected] > > > > Le jeu. 11 juil. 2019 à 04:50, Francis Chuang > > <[email protected]> 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 < > >>> [email protected]> 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 > >>>> > >>> >
