Repository navigation
Run the OpenJDK tests in CI from the built bundle - #32
Conversation
…out of the JDK cache
…s the VM they run on
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 49 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
There was a problem hiding this comment.
The PR switches OpenJDK test jobs to run from the built bundle (dist/node.js) instead of src/node.ts, adding a pnpm build step and --vm dist/node.js flag. It narrows the JDK cache to only jdk-* and dejavu-* directories (excluding boot snapshots), and updates scripts/jtreg/select.ts to treat scripts/build-web.ts as a test-affecting file since it produces the bundle. Measured CI time drops ~16% (81m to 68m total).
review-bot, model nvidia/nemotron-3-ultra-550b-a55b:free, verdict approve
The OpenJDK test jobs start one VM per test action, 2,524 tests in all, through
src/node.ts. Node then loads and type-strips about 60 source modules for each VM. The bundleddist/node.jsstarts faster, about 0.4 s less per VM on a small ARM board, so the jobs now build it once (6 s) and run every test VM from it with--vm dist/node.js. CI then also tests the file the package ships.Since the bundle is now what the tests run on,
scripts/jtreg/select.tscountsscripts/build-web.tsas part of that VM. A change to it runs the OpenJDK tests.The JDK cache in both workflows now covers only the downloads
scripts/build-jdk.shkeeps there (jdk-*,dejavu-*). Boot snapshots default to~/.cache/java-web/snapshots, and a cache miss would otherwise save them along with the JDK.Measured as two full runs (all 2,524 tests, 4 shards) of the same commit, one after the other, on GitHub-hosted runners:
src/node.tsdist/node.jsThat is 16% less runner time, and the slowest shard, which sets how long a pull request waits, went from 23m 10s to 18m 49s. Shard times vary from run to run, so a single comparison is rough; the total is the steadier number. Every test passed in both runs.
Checks:
node scripts/jtreg/select.ts <base>still selects all tests for a workflow change.