Hi David, On Mon, Dec 20, 2021 at 10:23 PM David Jencks <david.a.jen...@gmail.com> wrote: > > (Mostly general info, everyone please read) > > Hi Antonin, > > Sorry, somehow I missed this earlier! > > This work should help with that issue. I’m finding it really great for stuff > I do, it’s also really easy to adapt to create a website PR for integrating > lots of branch changes, cf. https://github.com/apache/camel-website/pull/729 > <https://github.com/apache/camel-website/pull/729>. > > I’m going to be working on my “referential integrity” idea next (unless more > documentation fires break out :-). This will touch every active branch of > every subproject, and unless someone objects I’m going to install the > local-build stuff everywhere to make it easier for myself :-), so it should > soon be pretty easy for everyone to try it on their favorite parts of camel.
+1 this is great work and it'll help us in the long run. I think you're doing it carefully and conscientiously taking into account not to be disruptive. Did we already update the README's, so folk understand how to use `local-build.sh`? > It’s not a problem for me since I basically only work on the website, but I > would imagine two major annoyances of the current system for everyone else > are: > > (1) You have to build the full site at least once, which takes annoyingly > long (7 minutes?). > (2) You have to build the UI locally, which is tricky on non-linux systems. > > For (1), building the site manifest as part of the regular website build so > the latest can always be downloaded would make it so you can always do a > quick local partial build, although you won’t get a very usable local > website: just the local stuff will be there locally. It would detect the > same errors as a the current local build, but not xref problems into the > local changes: this (currently) requires a full build. Still, I think this is a great step forward, we can detect some issues early and quickly, I'm sure we can improve to detect most issues in subsequent refinements > For (2), one simple option is just checking the built UI bundle into git. > > A further annoyance that I experience is that the built website is checked > into a branch of camel-website. This means whenever you pull camel-website, > you get the latest published website which is a lot of changes, along with > the tiny changes that might or might not have occurred since your last update. Nicola touched upon this in PR#537[1], would that be a better option? > I would like us to move the published website to a different repo. This > would also allow us to keep the website history, which would partly solve the > problem of docs for outdated component versions that we’ve dropped from the > active website. I also think from some comments about the old svn site > publishing system that infra expects website history to be preserved, > although I haven’t asked explicitly. I’ve set this up in a couple other > projects, and it’s pretty easy to do. I've chatted with INFRA a while back about the size of the git repository that was causing issues with the publish, and the workaround for that issue was to do what we do now and squash the commits before pushing. If we preserve history I think we'll end up with the same issue again. I don't understand the need of having the history of the website build result preserved, given that the output is optimized, changes can be seen much clearer and easier in the website sources. And I don't think there is much difference in having a separate repository vs a separate branch for publishing. 2c zoran [1] https://github.com/apache/camel-website/pull/537 -- Zoran Regvart
