Hi Murukesh, That is a good question. To clarify, I meant that if we changed the site to be serviced from the 'asf-site' branch the master branch would be cleaner from that point forward.
However, now that you mention it, I do like the idea of cleaning the entire master branch. Given that this alters the repository history, we might want to do such a change in a phased approach. e.g. 1. Change production site to be served from 'asf-site' branch. 2. Make a copy of the master branch called master_archive (or something similar) - this can be done sometime later after Step 1. 3. Clean master branch using bfg. 4. Keep the master_archive branch until we think it is no longer needed - we could keep the branch anywhere from a few days to a few years. Let me know what you think. Regards, Anthony On Fri, 1 May 2020 at 18:18, Murukesh Mohanan <murukesh.moha...@gmail.com> wrote: > For clarification, when you say "this would clean the master > branch history", would the content directory be removed from past commits > using bfg or similar tools? > > (I'm fine with either way; just curious.) > > On Fri, 1 May 2020, 07:12 Anthony Grasso, <anthony.gra...@gmail.com> > wrote: > > > Hi everyone, > > > > Thanks to hard work by Mick every push to the cassandra-website *src/* > > directory in master is now automatically deployed to > > https://cassandra.staged.apache.org/. The automation is carried out by a > > Jenkins job at https://ci-cassandra.apache.org/job/cassandra-website/. > > This > > is really useful because it allows us to preview our changes in the > staging > > site before we push them to the production site! > > > > With the above change in place, the process to deploy a change to the > > production site is. > > 1. Commit your change to the *src/* directory in the master branch. > Jenkins > > will now automatically generate the (HTML) site pages in *content/* > > directory on the asf-staging branch. > > 2. Preview your changes on the staging site: > > https://cassandra.staged.apache.org/. > > 3. If the changes look good, then merge the *content/* directory on the > > asf-staging branch to the master branch using: > > > > > > $ git merge asf-staging > > $ git push > > > > > > An issue with the above process is the master branch history is now going > > to get polluted with the auto-generated content commits. Even without the > > Jenkins automation, the process to publish to the production site still > had > > the issue where commits to the master branch included both the *src/* and > > *content/* directory changes. A small one line change to the *src/* > > directory, could result in changes to hundreds of pages in the *content/* > > directory. > > > > Rather than serving the production site from the *content/* directory on > > the master branch, is there any objection to serving it from the asf-site > > branch? This would mean that the last step in the above process would be > > performed on the asf-site branch rather than the master branch. In > > addition, there would be no need to have a *content/* directory on the > > master branch. The *content/* directory from which the production site is > > served would live in the asf-site branch. This would clean the master > > branch history, hiding the generated *content/* directory and the > unwieldy > > content changes generated by Jenkins user. > > > > Let me know what you think about the proposed change. > > > > Regards, > > Anthony > > > > On Tue, 21 Apr 2020 at 16:40, Mick Semb Wever <m...@apache.org> wrote: > > > > > For our cassandra-website repository, any changes to our website can > now > > > first be staged at https://cassandra.staged.apache.org/ > > > > > > The staged website comes from the content/ directory on the > `asf-staging` > > > branch. > > > > > > regards, > > > Mick > > > > > >
