djencks commented on pull request #667: URL: https://github.com/apache/camel-website/pull/667#issuecomment-966591001
By its nature, the Antora build has to have major network access to GitHub to get the content. I can’t really tell, but it looks like rebuilding unplugged for a different architecture doesn’t use any or significant network access. Certainly the rebuild time is unnoticeable compared to the Antora build time. Having the caches set up properly seems like a really good thing to me, but making the unplugged stuff need to be linux x86 seems to me to be more complex than it’s worth. However, the scripts I came up with make it possible for me to set this up before commit, at the cost of having a really big problem dealing with the .yarn/unplugged during local development. I don’t think running a local build in docker is practical, both because of the OOM errors I’m experiencing (see zulip) and because I can’t access the local checkouts. It might be possible to fix these but I think requiring a local build to be done in docker is a ridiculous constraint. So, I’m willing to deal with the complexity of the .yarn/unplugged but just barely and under protest. I really don’t think it’s worth it. > On Nov 11, 2021, at 11:49 AM, Zoran Regvart ***@***.***> wrote: > > > What is your goal here? > > The intent is to have the most reliable and the fastest build of the website possible on ci-builds.a.o. The performance is perhaps not immediately obvious, apart from getting the changes quickly published, the limiting factor of ci-builds.a.o is that it has only a few agents available to build websites, so any job that takes up too much time prevents other projects utilizing ci-builds.a.o to build their website. If we access the network from ci-builds.a.o this endangers both the performance and reliability of the build. Caching dependencies and having a nearly offline build at ci-builds.a.o is the aspired goal. How yarn is trying to do that and the argumentation for it can be seen on Zero-Installs <https://next.yarnpkg.com/features/zero-installs>. > > Docker is a Linux technology (for the most part), so when running Docker on any architecture you're running a Linux process inside a Linux (virtual) machine. I don't know if Docker has support for ARM, and if it does it might still opt to run only Docker itself as ARM and containers as x86. Container images are architecture dependent, and node image <https://hub.docker.com/_/node> does have an ARM variant, so depending on what Docker chooses to support on the M1 Macs, whether it will run as ARM native and run ARM containers, or with whichever means (Rosetta) end up running x86 containers -- yes the cache might vary. > > After writing that I went to the Docker website and found this <https://docs.docker.com/desktop/mac/apple-silicon/>, which says that the Apple Silicon version of Docker Desktop can run both ARM and x86 containers. x86 containers can be run using --platform linux/amd64 parameter. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/apache/camel-website/pull/667#issuecomment-966578998>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAELDXTD36KIR6KBWISIDWLULQM4RANCNFSM5HYKMJNQ>. > -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
