FYI - Applying 11/3/2022 and 11/4/2022 Commits in XO from Sources
-
FWIW, today I'm having trouble building with 4GB --
[08:34:41] Starting 'copyAssets'... transforming (10) ../../node_modules/@vue/runtime-dom/dist/runtime-dom.esm-bundler.jsKilled error Command failed with exit code 137. info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command. ERROR: "type-check" exited with 137. * @xen-orchestra/lite:build − Error: 1 <snip> [08:37:56] Finished 'copyAssets' after 3.23 min [08:39:37] Finished 'buildScripts' after 4.92 min [08:39:37] Finished 'build' after 4.92 min ✖ 1 error Command failed with exit code 1. -
I kept my VM at 4 GB after making the report the other day and haven't had any issues since. I even updated again this morning (after I noticed the large number of commits from yesterday and this morning) and everything ran just fine. The only thing out of the ordinary I noticed was I am still getting the "chunk" error message during the process.
(!) Some chunks are larger than 500 KiB after minification. Consider: - Using dynamic import() to code-split the application - Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/guide/en/#outputmanualchunks - Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.That hasn't caused any issues, as far as I see. Everything appears to be working as it should!
-
When I (re)build on my 3 GB vm i use this before in order to keep nodejs at bay
export NODE_OPTIONS='--max-old-space-size=3072'And then it runs smoothly
-
@hoerup Unfortunately, that doesn't help in my situation. I recently upgraded the VM to Ubuntu 22.10, so maybe that is contribution to the problem.
-
@Danp I'm using Debian Bullseye... I am able to run the updates now, but still see that same "chunk size" error notice you initially reported. Still, it seems you have it even worse...
-
I'm running daily installation from sources on multiple different OS's. All have the same specs: 2vCPU/4GB RAM. This has worked flawlessly for a long time. Recently (starting from 4th/5th Nov) i've started to see OOM errors almost daily during
yarn buildwhich then cause it to fail with following error:Using polyfills: No polyfills were added, since the `useBuiltIns` option was not set. [01:23:25] Finished 'copyAssets' after 36 s [01:24:33] Finished 'buildScripts' after 1.73 min [01:24:33] Finished 'build' after 1.73 min ✖ 1 error Command failed with exit code 1.It isn't consistent, sometimes it's debian that fails, sometimes ubuntu, sometimes centos/almalinux and so on. Something has definitely changed in the build procedure that eats more RAM than it used to.
I’m fine with increasing the RAM if needed. Just wanted to point this out if there’s something out of the ordinary with latest changes.
-
@ronivay said in FYI - Applying 11/3/2022 and 11/4/2022 Commits in XO from Sources:
Something has definitely changed in the build procedure that eats more RAM than it used to.
Agreed. Maybe @julien-f can add some insight into what has changed and how to successfully build from sources.
-
I believe this was due to the inclusion of XO Lite on the
masterbranch.I've limited the number of packages built concurrently: https://github.com/vatesfr/xen-orchestra/commit/08298d3284119ad855552af36a810a3a9a006759
Tell me if that helps
-
@julien-f I just ran a "yard build" this morning, and other than still seeing the chunk error message:
(!) Some chunks are larger than 500 KiB after minification. Consider: - Using dynamic import() to code-split the application - Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/guide/en/#outputmanualchunks - Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.Everything else ran fine... no errors or OOM issues.
-
-
@julien-f haven't seen OOM's after this so looks good, thank you.
-
Thanks for sharing
