Hey everyone,
Last month, I mentioned that I was going to start working on automated
website builds for Calcite and its sub-projects. I have completed most
of the work but am current stuck on how to trigger them.
The commits are currently in this branch:
https://github.com/apache/calcite/tre
Francis>- For Javadocs (Calcite and Avatica) trigger and build when a final
version is tagged.
I think javadocs could be built on each push to site branch.
Vladimir
This will be my fallback solution if I can't get the job to trigger on a
tag push or a push to the site branch correctly.
The reason I wanted to build the javadocs only when a final release's
tag is pushed is because the javadocs takes around 20 minutes to build
on the node, whereas the site t
All sounds great to me. Thanks Francis! Unfortunately I don't know
much about Jenkins so I'm not sure how much help I can be here.
--
Michael Mior
mm...@apache.org
Le jeu. 4 juil. 2019 à 13:21, Francis Chuang
a écrit :
>
> Hey everyone,
>
> Last month, I mentioned that I was going to start workin
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 pu
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 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
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
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
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
>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.apa
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
java
> On Jul 14, 2019, at 3:27 PM, Francis Chuang wrote:
>
> 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?
That has b
In general, I prefer the Javadocs to reflect the latest release. I find
that when pulling dependencies into my projects (in languages such as
Go, Javascript, PHP, etc), I tend to pin to the latest release, unless
there's a critical and unreleased change on master that I really need.
I've been b
Francis> I've been burnt in the past where generated documentation is for
master
Francis> and not the latest release, causing some confusion.
On contrary, it is better when the documentation has version selector, so
one could pick an appropriate version.
Then "snapshot" documentation is good for t
Many projects and also JDK adopts the approach of version selector in the
Javadoc so I think people are accustomed to searching for the right
documentation.
I don't really mind if we follow this approach or not but if it simplifies
the automation process maybe this would be another advantage.
Bes
I find my documentation - even for Calcite - using google. The more versions we
keep on the site, the greater chance that I am looking at the wrong version.
So I vote for keeping only one version, the latest release.
Julian
> On Jul 15, 2019, at 10:53 PM, Vladimir Sitnikov
> wrote:
>
> Fran
17 matches
Mail list logo
