Well, actually you are claiming that the website build is reproducible. I don’t think there’s any evidence for that, but perhaps it doesn’t matter.
However, for the Antora portion, it would be helpful to record the git commit OIDs for each branch in the build each time the site is published. David Jencks > On Nov 2, 2020, at 4:14 PM, David Jencks <david.a.jen...@gmail.com> wrote: > > Perhaps I don’t know how often the website is published. If it’s published > after every git update, then indeed history is not so essential. Indeed, > then, perhaps doing git commit —amend —no-edit for each update would be fine > (and squashing all earlier commits) > > Personally I’d avoid any SVN solution. The git + asf-site branch solution > seems pretty nice to me. > > David Jencks > >> On Nov 2, 2020, at 2:49 PM, Zoran Regvart <zo...@regvart.com> wrote: >> >> Hi David, >> And at any point we can recreate the state of the `asf-site` branch by >> rebuilding and pushing the content of the `public` directory, so I >> don't see history of that being important as it is a pure byproduct of >> the state on the `master` branch. >> >> I don't think we ever look at history on the `asf-site` branch, at >> least I haven't, if someone has and has a compelling use case I'm >> willing to go back on this. >> >> I've been looking at INFRA wiki and I've found a way to not use the >> `asf-site` branch in the same git repository, it seems that we can >> push to SVN directly[1], that needs to be investigated. I'm not >> certain what drawbacks it entails. >> >> zoran >> >> [1] >> https://cwiki.apache.org/confluence/display/INFRA/Publish+a+huge+project+website+without+checking+it+into+Git >> >> On Mon, Nov 2, 2020 at 11:13 PM David Jencks <david.a.jen...@gmail.com> >> wrote: >>> >>> I don’t think killing the history is a good idea at all, and I’m not sure >>> what infra would think about it. Perhaps you could suggest that cloning >>> with depth 1 would be appropriate? >>> >>> Personally I think that having a separate camel-site repo with just the >>> published site with all history would make even more sense. >>> >>> David Jencks >>> >>>> On Nov 2, 2020, at 4:04 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>> >>>> Hi Zoran >>>> >>>> Yeah its fine with me. >>>> >>>> On Mon, Nov 2, 2020 at 1:00 PM Zoran Regvart <zo...@regvart.com> wrote: >>>>> >>>>> Hi Cameleers, >>>>> when cloned the camel-website repository is 1.3GB in size. I think >>>>> that's because of the large number of commits in the `asf-site` >>>>> branch. As a reminder when we build the website, to publish it we have >>>>> to push the resulting files to the `asf-site` branch. >>>>> >>>>> I think it would help if we were to squash to commits there. This >>>>> would, of course, mean we would lose the history on that branch. >>>>> >>>>> I was thinking we would keep the last 10 commits unsquashed, and >>>>> squash all older commits (apart from the initial one), with something >>>>> like: >>>>> >>>>> git -c core.editor="sed -i 2,/$(git log --skip=10 -1 >>>>> --pretty=format:%h)/s/^pick/squash/" rebase --interactive >>>>> 1586f65bf7f24784dc99e22aff08e44c7dbb1920 >>>>> >>>>> That `sed` would skip the first line and replace until the 11th commit >>>>> (hash printed by that `git log`) has been seen all "pick" with >>>>> "squash". >>>>> >>>>> I'd put this as a step in the deploy part of the pipeline[1]. >>>>> >>>>> WDYT? >>>>> >>>>> zoran >>>>> >>>>> [1] >>>>> https://github.com/apache/camel-website/blob/8cafa694e13b72d3013b7de2b956da73f55ca2b4/Jenkinsfile#L89 >>>>> -- >>>>> Zoran Regvart >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> http://davsclaus.com @davsclaus >>>> Camel in Action 2: https://www.manning.com/ibsen2 >>> >> >> >> -- >> Zoran Regvart >
