Stamatis, Instead of removing the manual instructions[1], I think it's better to rephrase it to mention the automation site releasing as Francis already suggested. This will be helpful for the next RMs.
[1] https://github.com/apache/calcite/blob/main/site/README.md#publishing-the-website Stamatis Zampetakis <[email protected]> 于2022年9月14日周三 22:01写道： > Thanks for the feedback Benchao! > > CALCITE-3129 was committed on 31/03/2022. > CALCITE-5092 was reported on 13/04/2022. > > According to the comments in CALCITE-5092, the problem was resolved after > releasing 1.31.0. > I assume that automation scripts, introduced by CALCITE-3129, were > triggered after the release and correctly updated the javadoc fixing the > problem mentioned in CALCITE-5092. > With the automation enabled we shouldn't touch the calcite-site repo [1] > manually thus I would suggest removing the manual instructions from here > [2] to avoid confusion. > If we happen to find a problem in the site generation then we should > investigate the root cause and if necessary modify the automation scripts. > > Best, > Stamatis > > [1] https://github.com/apache/calcite-site > [1] > > https://github.com/apache/calcite/blob/main/site/README.md#publishing-the-website > > On Wed, Sep 14, 2022 at 2:10 AM Benchao Li <[email protected]> wrote: > > > Stamatis, > > > > I didn't know CALCITE-3129 before. > > I was tracking CALCITE-5092 at that time, and I did some experiments > > locally, > > and reproduced the problem reported in CALCITE-5092, hence I thought that > > this was the reason. I added that section in case that we will run into > the > > same > > problem. > > > > [1] https://issues.apache.org/jira/browse/CALCITE-5092 > > > > Stamatis Zampetakis <[email protected]> 于2022年9月13日周二 15:23写道： > > > > > The new section about publishing-the-website [1] has been added rather > > > recently. > > > > > > @Benchao Since you added this section can you explain the intention > > behind > > > it? > > > As Francis mentioned, after CALCITE-3129, the automatic workflow should > > > take care of everything. > > > > > > Best, > > > Stamatis > > > > > > [1] > > > > > > > > > https://github.com/apache/calcite/blob/main/site/README.md#publishing-the-website > > > > > > On Sun, Sep 11, 2022 at 2:29 AM Francis Chuang < > [email protected] > > > > > > wrote: > > > > > > > It's fine to update the calcite.version and the news item in the same > > > > commit as the workflow only looks at site files that were changed. > > > > > > > > The commits should always be pushed to main. The workflow > automatically > > > > cherry-picks the commit to site if it satisfies the following rules: > > > > > > > > > > > > > > https://github.com/apache/calcite/blob/main/.github/workflows/publish-non-release-website-updates.yml#L23 > > > > > > > > Once cherry-picked to site, it automatically builds the site and > > > > publishes it. > > > > > > > > In summary, commits should always be pushed to main and the workflow > > > > will take care of the rest. Would you be able to update > > > > https://github.com/apache/calcite/blob/main/site/README.md with this > > new > > > > information? I think it would be very helpful for the next RM. I > > noticed > > > > there's a section talking about copying the generated site to the > > > > calcite-site repo > > > > ( > > > > > > > > > > https://github.com/apache/calcite/blob/main/site/README.md#publishing-the-website > > > ) > > > > > > > > but I don't think we need to do that at all since the workflow / > > > > automation takes care of it. Maybe it can be removed? > > > > > > > > Francis > > > > > > > > > > > > On 11/09/2022 10:17 am, Julian Hyde wrote: > > > > > Thanks for the information, Francis. > > > > > > > > > > I wrote the news item after the release, as part of the commit that > > > > > advanced the version number, and pushed that commit to main. > Should I > > > > have > > > > > split it into separate commits? Or pushed to site rather than main? > > > > > > > > > > FWIW, I was able to get the site to rebuild by making a trivial > > change > > > to > > > > > the news item and pushing to main. I then used a force-push to back > > it > > > > out > > > > > from both main and site branches. So everything is good now. The > > > > artifacts, > > > > > news item, history, and javadoc for 1.32 are all deployed. > > > > > > > > > > Julian > > > > > > > > > > On Sep 10, 2022, at 4:05 PM, Francis Chuang < > > [email protected]> > > > > > wrote: > > > > > > > > > > The site and javadocs are automatically published when a release is > > > > tagged > > > > > using this workflow: > > > > > > > > > > > > > > > https://github.com/apache/calcite/blob/main/.github/workflows/publish-website-on-release.yml > > > > > > > > > > New news items should be automatically published via this workflow: > > > > > > > > > > > > > > > https://github.com/apache/calcite/blob/main/.github/workflows/publish-non-release-website-updates.yml > > > > > > > > > > I can see that the workflow for the news item failed due to the > > commit > > > on > > > > > site being on main already: > > > > > > > > > https://github.com/apache/calcite/runs/8286036230?check_suite_focus=true > > > > > > > > > > Did you manually cherry-pick/rebase the commit to main? I think > I'll > > > need > > > > > update the workflow to account for this edge case. > > > > > > > > > > Francis > > > > > > > > > > > > > > > On 11/09/2022 2:57 am, Julian Hyde wrote: > > > > > > > > > > Does anyone (probably a previous release manager) know whether the > > > > > site, javadoc, news are published automatically by release scripts? > > > > > It seems that the site and javadoc are generated automatically on > > > > release. > > > > > But if I add a news item after the release and push it to main, > does > > > > > the site get regenerated? It doesn't seem so [1]. The instructions > > > > > seem to indicate that pushing to the 'site' branch is sufficient > [2]. > > > > > Julian > > > > > [1] https://calcite.apache.org/news/ > > > > > [2] > https://calcite.apache.org/docs/howto.html#publishing-a-release > > > > > > > > > > > > > > > > > > -- > > > > Best, > > Benchao Li > > > -- Best, Benchao Li
