gristlabs_grist-core

Commit Graph

Author	SHA1	Message	Date
Paul Fitzpatrick	bcbf57d590	(core) bump mocha version to allow parallel tests; move more tests to core Summary: This uses a newer version of mocha in grist-core so that tests can be run in parallel. That allows more tests to be moved without slowing things down overall. Tests moved are venerable browser tests; only the ones that "just work" or worked without too much trouble to are moved, in order to keep the diff from growing too large. Will wrestle with more in follow up. Parallelism is at the file level, rather than the individual test. The newer version of mocha isn't needed for grist-saas repo; tests are parallelized in our internal CI by other means. I've chosen to allocate files to workers in a cruder way than our internal CI, based on initial characters rather than an automated process. The automated process would need some reworking to be compatible with mocha running in parallel mode. Test Plan: this diff was tested first on grist-core, then ported to grist-saas so saas repo history will correctly track history of moved files. Reviewers: jarek Reviewed By: jarek Subscribers: jarek Differential Revision: https://phab.getgrist.com/D3927	12 months ago
Paul Fitzpatrick	4be4acca6e	run grist-core test batches in parallel (#444 ) This sets up a framework for running tests in parallel. It increases the total time taken (since some steps are repeated) but reduces the turn-around time significantly overall. The main objective is to make it possible to release more test batches to grist-core without bringing CI to a crawl. The clever little test/split-test.js script is from the Grist Labs mono-repo and is Dmitry's work. I considered doing the build in one job, and copying it to test jobs, since it feels wasteful to repeat it. That may be worth trying, especially if we start getting jobs backing up (total concurrent Linux jobs on free plan is quoted at 20). It might also be worth looking at doing some tests in parallel on the same worker, perhaps using the relatively new MOCHA_WORKER_ID feature, since the tests are often not actually CPU or I/O bound.	1 year ago

Author

SHA1

Message

Date

Paul Fitzpatrick

bcbf57d590

(core) bump mocha version to allow parallel tests; move more tests to core

Summary:
This uses a newer version of mocha in grist-core so that tests can be run in parallel. That allows more tests to be moved without slowing things down overall. Tests moved are venerable browser tests; only the ones that "just work" or worked without too much trouble to are moved, in order to keep the diff from growing too large. Will wrestle with more in follow up.

Parallelism is at the file level, rather than the individual test.

The newer version of mocha isn't needed for grist-saas repo; tests are parallelized in our internal CI by other means. I've chosen to allocate files to workers in a cruder way than our internal CI, based on initial characters rather than an automated process. The automated process would need some reworking to be compatible with mocha running in parallel mode.

Test Plan: this diff was tested first on grist-core, then ported to grist-saas so saas repo history will correctly track history of moved files.

Reviewers: jarek

Reviewed By: jarek

Subscribers: jarek

Differential Revision: https://phab.getgrist.com/D3927

Paul Fitzpatrick

4be4acca6e

run grist-core test batches in parallel (#444 )

This sets up a framework for running tests in parallel.
It increases the total time taken (since some steps are
repeated) but reduces the turn-around time significantly
overall.

The main objective is to make it possible to release more
test batches to grist-core without bringing CI to a crawl.

The clever little test/split-test.js script is from the
Grist Labs mono-repo and is Dmitry's work.

I considered doing the build in one job, and copying
it to test jobs, since it feels wasteful to repeat it.
That may be worth trying, especially if we start getting
jobs backing up (total concurrent Linux jobs on free plan
is quoted at 20).

It might also be worth looking at doing some tests in
parallel on the same worker, perhaps using the relatively
new MOCHA_WORKER_ID feature, since the tests are often not
actually CPU or I/O bound.

2 Commits (519f2f4fb66683f975dcc3840cc8c705278ffa34)