Repository navigation
Speed up the spec suite with parallel runs and a lighter app copy - #213
Conversation
Generator specs copied the example app per example, including an untracked node_modules that CI never has and Yarn PnP deletes anyway. Specs now run under parallel_tests via bin/ci, each process in its own spec/tmp<N>, with per-process JUnit output on CI. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
| #!/usr/bin/env sh | ||
| set -e | ||
|
|
||
| bundle exec parallel_rspec "$@" |
There was a problem hiding this comment.
I guess this is okay, but seems not entirely necessary to move into a separate bin/ci 🤔
There was a problem hiding this comment.
makes it easier to run locally. People are familiar with calling bin/ci in the terminal
There was a problem hiding this comment.
It is mostly so CI and local run the exact same command: parallel_rspec and any flags we add later live in one place, and the README can point at one entry point. Happy to inline it into ci.yml if you would rather not have the extra file.
| cleanup_test_app | ||
| FileUtils.cp_r(TEMPLATE_APP_PATH, destination_root) | ||
| FileUtils.mkdir_p(destination_root) | ||
| # node_modules is untracked, absent on CI, and removed by Yarn PnP on first use |
There was a problem hiding this comment.
That's weird... Are we even using Yarn PnP on this repo? I think most of them have the PnP stuff turned off (but also might be some other problematic things in our ci.yml, like missing a general node/yarn setup step in the first place)....
There was a problem hiding this comment.
@wesrich I think that's correct, but I also think we should keep it. As you can see in the PR description - even without parallel tests, not copying node_modules alone (as in that's the only change) cuts the spec time in half!
There was a problem hiding this comment.
Good catch: the PnP reason was wrong. Generators write .yarnrc.yml with nodeLinker: node-modules before their first yarn call, so PnP never applies during specs. The real reason it is safe: node_modules is untracked and absent on CI, and the suite already passes there without it. I corrected the comment in abd2984 and fixed the PR description.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Why?
The spec suite took 5m14s locally and 7m13s on CI, which was close to the job's 10-minute timeout. It now takes about 1 minute locally and 3–5 minutes on CI.
What Changed
bin/ci(parallel)bin/ci, 4-core runner)example_rails_current/node_modulesfor each example. That folder is untracked and absent on CI, so the specs already pass without it; generators that need packages install them. Skipping it accounts for the local one-process speedup.bin/ciruns the suite withparallel_tests. Each process copies the example app into its ownspec/tmp<N>, so processes do not collide.bin/ci..rspec_parallelwrites one JUnit file per process whenCIis set, and the report step collectstmp/rspec*.xml.parallel_rspecloads.rspec_parallelinstead of.rspec, so that file repeats--require spec_helper. Plainbundle exec rspecstill uses.rspec, unchanged.Parallel runs are now limited by the slowest single file.
parallel_testssplits work by file, andmodals_generator_spechas 7 examples that each run a realyarn add. I did not fake theyarncalls, because the specs check the realpackage.jsonoutput.Pre-merge checklist
bin/ciand running single specs)Notes
Please don't commit version changes within your PR. Versioning, releasing, and changelog entries are managed through the Release workflow.
🤖 Generated with Claude Code