Closed dackyD closed 2 years ago
Could you please try rebooting your machine to see if that fixes your problem? Sometimes a chrome instance can get stuck, which may be the cause of your problem.
If that doesn't work, could you please try creating and using a Wallaby configuration file instead of automatic configuration, with the following content:
wallaby.js
module.exports = ({
autoDetect: true,
env: {
kind: 'chrome',
// NOTE: you may need to update the path on your system
runner: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
},
workers: {
initial: 1,
regular: 1
}
});
Finally, if it's still not working for you, please revert your project commits to before Wallaby stopped working (e.g. 2 weeks ago). If you do that, does Wallaby work for you? If so, you may try bisecting your commits to identify the change that is causing a problem.
Rebooting the machine didn't help. I made the configuration file as you suggested and it worked like a charm. I was wondering what could be the impact of this configuration file vs automatic configuration in terms of performance and resources?
Another thing is, is there a configuration file that works for both mac and windows users?
Thanks for the support again. I feel so unproductive not using wallaby just for a couple of days.
I was wondering what could be the impact of this configuration file vs automatic configuration in terms of performance and resources?
If you remove the workers
setting:
module.exports = ({
autoDetect: true,
env: {
kind: 'chrome',
// NOTE: you may need to update the path on your system
runner: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
}
});
is it still working? If so, there should not be any impact on performance and resources, and the issue seems to be related to some possibly newly installed version of Chrome in your system (maybe Chrome Canary).
Another thing is, is there a configuration file that works for both mac and windows users?
Wallaby is using Chrome Launcher package to find and and launch an instance of Chrome for running your tests. The highest priority for all OS is using process.env.CHROME_PATH
value if specified. So I think the safest bet is to set the CHROME_PATH
environment variable to the path of your desired (for testing) Chrome executable. In this case you/your team will not need any Wallaby config at all.
For VS Code:
Open Settings (JSON)
command from command palette,
add the following setting there and save it:
...
"wallaby.env": {"CHROME_PATH": "..."},
...
For other editors:
launchctl setenv CHROME_PATH ...
.setx
command: setx CHROME_PATH "..."
Issue description or question
Wallaby suddenly stopped working until 2 days ago and I have this error message in my webstorm Failing tests tab: Test run failure: Sandbox load failed, status: failed: socket hang up.
Running the test manually with npm seems to be just fine.
Wallaby diagnostics report