Christopher, IIRC the local build is likely sufficient. It may have been that I failed to use it in all cases. I do remember in the past merging some PR's then noticing on the staging site that the links or formatting were not right. I think Dan's suggested change to the git workflow might also be useful (Auto-deply to staging on merge to staging branch, auto-deploy to apache.org on merge to main).
On Fri, Apr 7, 2023 at 10:03 PM Christopher <ctubb...@apache.org> wrote: > Hi Dave, > > How often would you estimate the diff in the PR is insufficient, and > you need a full site build to get a sense of how the change is viewed? > I imagine this might come up with some longer blog posts with a lot of > complex layout and references to docs, etc., but that doesn't happen > very frequently. I don't know if there are other times you feel it > would be helpful or how often those occur. > > Aside from local builds, are your concerns mitigated in any way by the > following? > > 1. Code reviewers checking the proposed changes for layout-related > mistakes before merging, or > 2. Subsequent commits to correct initial publication mistakes would > also be streamlined. > > (For reference, the local build is documented in the website README at > > https://github.com/apache/accumulo-website/blob/main/README.md#local-builds-for-testing > ) > > On Fri, Apr 7, 2023 at 7:24 PM Dave Marion <dmario...@gmail.com> wrote: > > > > I find the staging site useful for reviewing changes before publishing. > > There are some things that are not the easiest to review in a markdown > > diff. Especially since the markdown is transformed to what is ultimately > > displayed. I have no issue with streamlining this, I'll just need to > > remember to be more careful. There is a way to deploy locally IIRC, I'll > > just have to use that. > > > > On Fri, Apr 7, 2023 at 6:34 PM Christopher Shannon < > > christopher.l.shan...@gmail.com> wrote: > > > > > +1 to make the change. I agree that when PRs are merged we generally > just > > > want to publish immediately. > > > > > > FWIW, this is how we do things for the ActiveMQ website > > > <https://github.com/apache/activemq-website> and it works fine, we > just > > > publish and there is no staging. > > > > > > On Fri, Apr 7, 2023 at 3:49 PM Christopher <ctubb...@apache.org> > wrote: > > > > > > > Hi Accumulo Devs, > > > > > > > > When I first set up the automation using .asf.yaml for Jekyll builds > > > > to go to the asf-staging branch, I expected us to get a bit more use > > > > out of the staging site at https://accumulo.staged.apache.org/ > > > > However, that really hasn't happened, and it seems that we basically > > > > almost always want to publish to the https://accumulo.apache.org > once > > > > we've approved a PR against the main branch and have a successful > > > > Jekyll build. > > > > Having the staging site is now just an unnecessary extra step to > > > > publish (that we sometimes forget to do for a while, even though it's > > > > trivial to run ./_scripts/publish.sh). I'm not sure it's adding any > > > > value. > > > > > > > > Perhaps we should just have Jekyll build directly to the asf-site > > > > branch and get rid of the asf-staging branch? > > > > > > > > The one benefit to the staging site is that, in theory, it's a > > > > conscientious decision to publish. But, I don't think we've ever come > > > > across any kind of situation where we wanted to stage the site, but > > > > then didn't immediately want to publish it. So, I'm not convinced > that > > > > extra step is adding any value, especially since we're almost always > > > > making the conscientious decision in GitHub when approving a PR to > > > > update the site already. > > > > > > > > Any thoughts or opinions on this? I'm leaning slightly towards > > > > streamlining this. > > > > > > > > Regards, > > > > Christopher > > > > > > > >
