Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(jest-core): don't use workers in watch mode if runInBand specified #14085

Merged
merged 7 commits into from
Aug 16, 2023

Conversation

benjaminjkraft
Copy link
Contributor

Summary

In #14059, I added code to say that if you use watch mode, even if you only run one test and one worker, we should still not run in band, because then a hard-crash in the test will crash the entire watcher. But the way the logic is written, this overrides even an explicit --runInBand, which can be useful if you really want to, say, attach a debugger to watch-mode; it's not the smoothest experience but it's better than nothing.

In this commit I make it so that if you explicitly say --runInBand that overrides everything else. (But if you just say --maxWorkers=1, or you just only have one test to run, we still use workers.) This required some replumbing; let me know if there's a better way.

Test plan

Ran unit tests

In jestjs#14059, I added code to say that if you use watch mode, even if you
only run one test and one worker, we should still not run in band,
because then a hard-crash in the test will crash the entire watcher. But
the way the logic is written, this overrides even an explicit
`--runInBand`, which can be useful if you really want to, say, attach a
debugger to watch-mode; it's not the smoothest experience but it's
better than nothing.

In this commit I make it so that if you explicitly say `--runInBand`
that overrides everything else. (But if you just say `--maxWorkers=1`,
or you just only have one test to run, we still use workers.) This
required some replumbing; let me know if there's a better way.
Copy link
Contributor

@mrazauskas mrazauskas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm.. I am not so sure why --runInBand should not use workers? That is not --doNotUseWorkers option. Performance should be better without workers, so perhaps this is all what shouldRunInBand() should take into account?

Something like --maxWorkers=0 could turn off workers. Just thinking out loud. Not sure if that is needed. I think, if tests run using workers or not is implementation detail and users shouldn’t have to care about that. If tests should run in parallel or in band is different problem already.

@SimenB
Copy link
Member

SimenB commented Apr 19, 2023

runInBand is explicitly meant to not use workers, so I think this is fine

@mrazauskas
Copy link
Contributor

mrazauskas commented Apr 19, 2023

runInBand is explicitly meant to not use workers, so I think this is fine

Ah.. That is absolutely fine with me. Less overthinking is always good (;

This approach makes the logic of shouldRunInBand() more simple and explicit. Also I think it is good idea to have runInBand included in the config object.

By the way, isn’t this check redundant, if runInBand gets added to the config object? Ignore this suggestion (see comment below).

https://github.com/facebook/jest/blob/77c2c6e00e0da58e242862237e541af4dde90d3c/packages/jest-config/src/getMaxWorkers.ts#L27-L28

@mrazauskas
Copy link
Contributor

It would be wrong to follow my suggestion above, because that is breaking change. maxWorkers value is passed around with config object, hence it can be used by any extension. Some of them might depend on the logic I was suggesting to alter.

@SimenB Looks like everything is in place. This PR is ready to land, if you are happy with it.

@benjaminjkraft
Copy link
Contributor Author

Something like --maxWorkers=0 could turn off workers. Just thinking out loud. Not sure if that is needed. I think, if tests run using workers or not is implementation detail and users shouldn’t have to care about that. If tests should run in parallel or in band is different problem already.

Yeah if for some reason this approach doesn't work that could be a good one. This just seemed like the simplest and most robust approach if it works.

@SimenB
Copy link
Member

SimenB commented Apr 22, 2023

/easycla

@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Apr 22, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

@benjaminjkraft
Copy link
Contributor Author

Oh, new CLA? Will need to get my company to sign the new one if so.

@SimenB
Copy link
Member

SimenB commented May 10, 2023

Yeah, it's Linux/JS Foundation now, sorry 😅

@netlify
Copy link

netlify bot commented Jul 27, 2023

Deploy Preview for jestjs ready!

Built without sensitive environment variables

Name Link
🔨 Latest commit a1f6a91
🔍 Latest deploy log https://app.netlify.com/sites/jestjs/deploys/64dccbbf2fcb830008d26a8f
😎 Deploy Preview https://deploy-preview-14085--jestjs.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@benjaminjkraft
Copy link
Contributor Author

Ok, sorry for the delay, finally got the CLA sorted and merged the changelog, so hopefully this is ready to go now!

Copy link
Member

@SimenB SimenB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@SimenB SimenB merged commit a515a16 into jestjs:main Aug 16, 2023
@SimenB
Copy link
Member

SimenB commented Aug 21, 2023

@cdoublev
Copy link

Workers are still used (code execution does not break in debugging tool) when --runInBand is set as a command line argument. I guess that is an oversight.

It works when I add the option here but I doubt this is the right way to go.

@SimenB
Copy link
Member

SimenB commented Aug 23, 2023

Yeah, I was actually debugging something earlier today and noticed the same thing

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants