Max workers

[jrr]

Summary

This PR fixes #8407, adjusting --maxWorkers behavior to act as an upper bound. With this change, Jest will use the lesser of the provided number and the number of CPU cores.

This better matches the behavior implied by the option's usage information.

Test plan

Unit tests have been updated to cover the changed behavior.

[facebook-github-bot]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need the corporate CLA signed.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[jeysal]

Thanks @jrr, left a few comments ;)
We should also wait if anyone has concerns about not allowing users to use more workers than cores (I guess you can still do it using a percentage, which is more explicit, so I think it's good).

[jeysal]

LGTM, let's see what others say :)

[jrr]

We should also wait if anyone has concerns about not allowing users to use more workers than cores

I'm a little hesitant about this, too. I can imagine situations where num_workers > num_cpus is appropriate, and this change would remove that as an option 🤔

(I guess you can still do it using a percentage, which is more explicit, so I think it's good).

I.. don't think you can. The percentage is checked to be within (0,100]:

https://github.com/facebook/jest/blob/ad4944d1fb8173ab9edf55b3036db8c1e26f726c/packages/jest-config/src/getMaxWorkers.ts#L22-L27

On the one hand, if we want to enable num_workers > num_cpus, it seems like the option should be something like --workers instead of --maxWorkers.

On the other hand, it'd be nice to maintain the capability for any existing num_workers > num_cpus users. One way to handle this would be to introduce a new notation in the maxWorkers value:

1. We could introduce something like --maxWorkers <7 for people like me, who want an upper bound of num_cpus.
2. Or we could decide to change the behavior of the existing option, and introduce a new value for the (few?) users who really do want num_workers > num_cpus; something like --maxWorkers 7!.

[github-actions]

This PR is stale because it has been open 1 year with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions]

This PR was closed because it has been stalled for 30 days with no activity. Please open a new PR if the issue is still relevant, linking to this one.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.