A build from the menu printed uname -p and sysctl hw.cpu64bit_capable
over and over and never reached its first package. With
METEOR_WAREHOUSE_DIR set and no SANDBOX, Meteor takes the running tool
to be wherever the warehouse's "meteor" link points - 3.5.4, the release
it was installed with - so with .meteor/release at 3.6-rc.1 every start
springboarded to 3.6.0-rc.1, found itself the wrong tool again and
springboarded again: 28 times in 20 seconds of meteor --version. The
earlier 1.1 GB build log was the same loop, its module trace printed
anew on every exec.
tools-env.sh and tools-env.bat now set SANDBOX=true beside the
warehouse, as Meteor's own self-test does; that one check is all it
changes. The Nextcloud test scripts and the dev-source runner, which set
the warehouse themselves, do the same. meteor --version now springboards
once, from the linked 3.5.4 to 3.6.0-rc.1.
tests/meteorSpringboardLoop.test.cjs checks both env scripts, that
nothing sets the warehouse without SANDBOX, and runs the installed
Meteor to count its springboards.
Thanks to xet7 !
Add Dev server nobuild to both build menus with shared URL and port options. Load checkout JavaScript and templates in memory using the installed Meteor toolchain; start its bundled MongoDB on the next port and wait for owned database shutdown.
Run server, Node, import, E2E and all supported Chromium, Firefox and WebKit regressions sequentially, stopping on failure. Preserve CommonJS semantics, native fetch, dynamic import namespaces and client source access boundaries. Document verified results and the remaining Windows and intermittent Firefox limits.
Thanks to xet7 !
Lauri Ojansivu