This version of ChromeDriver only supports Chrome version 83
It looks like you're using a Windows environment?
Yup, the Windows 2019 environment, which as of seven days ago is using chrome 81 (at least according to this https://github.com/actions/virtual-environments/blame/master/images/win/Windows2019-Readme.md#L573)
Hmm...the release notes for the most recent release (3 days ago) says it's on Chrome 83. (https://github.com/actions/virtual-environments/releases/tag/win19%2F20200524.1)
In any case. the solution is still to pin the chromedriver version to something compatible with the target environment.
It would be useful to be able to easily make use of the environment variable, though. The Windows release notes point out that it points to the driver exe. so that's useful to know. I'll create an issue for it...
Because I can pin to v81 to get tests passing now, but in a few days when the environment updates to v83 I'm gonna have the same issue.
I guess I could, in CI, interpolate the chrome version into the config?
Being able to use environment variables in the config would handle the GHA case (and would be generally useful). You can already use an
INTERN_ARGS environment variable to pass command line options, but it's not very ergonomic for something like this.
Unfortunately, there isn't a way to configure a path to a local webdriver executable, so the best solution for the moment is to pin the version in the config. Depending on the format of their CHROMEWEBDRIVER variable, you might be able to extract the local version from that and use it to set the webdriver version.
So I have unit tests running in the browser. How do I get those to run in a headless browser on my CI server?
@stdavis In a CI system, you'd run Intern from the command line, and use the Selenium tunnel (assuming the browser is on your CI system) to load and manage the browser. In your Intern config, you'd setup an environment for headless chrome (see https://theintern.io/docs.html#Intern/4/docs/docs%2Fhow_to.md/run-tests-with-headless-chrome). Note that your CI system would need Java (headless Java is fine) to run Selenium. If Java isn't an option, you can also interact with chromedriver directly, but it's a bit more work (better support for direct interaction with web drivers is in the works).
1 reply
Is Firefox on GitHub Actions really flaky? I feel like every third run fails with
Timeout: [POST http://localhost:4444/wd/hub/session / {"desiredCapabilities":{"name":"intern","idle-timeout":60,"browserName":"firefox","moz:firefoxOptions":{"args":["-headless"],"browser":"firefox"}}] connection refused
Since upgrading from Intern 3 to Intern 4 we have a number of files that have (much) lower code coverage.
I've been able to chase this down to test cases that use a (dojo) context require with a map to reroute dependencies to mock files. After the test case is finished, we clean up the loaded module (using
It seems that reloading a module with Intern 4 resets the coverage built up so far, whereas with Intern 3 this wasn't the case.
Any thoughts on how to work around this? Do we even consider this a bug?
I've been able to chase this down to test cases that use a (dojo) context require with a map to reroute dependencies to mock files. After the test case is finished, we clean up the loaded module (using
require.undef) to force-load it (without mocked dependencies) the next time it is needed.It seems that reloading a module with Intern 4 resets the coverage built up so far, whereas with Intern 3 this wasn't the case.
Any thoughts on how to work around this? Do we even consider this a bug?
Sry for the most noob question of the day but I am trying to set up a workflow (learning about Web Development) and it seems I can't intern to test against a browser. For Chrome it either says that the version is wrong, or that it cannot download 85.0 from the specified URL. Version 85.0 is however available from the official google API. With Firefox I get a
suide error occured. Can anyone tell me how to set this up?
Hi! Hmmm...it looks like the default webdriver versions used by Intern had slipped a bit. If you're using the most recent Intern, I pushed an updated list of webdriver versions that Intern should see the next time you run it. If you want to specify a version, you can use the
tunnelOptions property, like:"tunnelOptions":: {
"drivers": [ { name: "chrome", "version": "85.0.4183.87" } ]
}Error: Unable to load /tests/box.spec.ts
at HTMLScriptElement.<anonymous> @ node_modules/intern/browser/remote.js:168:45068
No unit test coverage for chrome on linux
TypeScript isn't (yet) supported in browsers, so you'll need to build your tests first. For example, using webpack, create a bundle that includes all of your unit tests, and then use that bundle in the browser. You can provide separate suites lists for Node and Browsers to keep using the TS suites in Node:
// intern.json
{
"node": {
"suites": "tests/**/*.ts"
},
"browser": {
"suites": "build/tests.js"
}
}
Just wanted to drop a note about this again. I'm constantly seeing test failures where Intern is unable to connect to Firefox on GitHub Actions. Any idea if this is a Firefox, GHA, or Intern issue? https://github.com/Kinto/kinto.js/runs/1167315492
Timeout: [POST http://localhost:4444/wd/hub/session / [...snip...] connection refused
Should
@theintern/digdug have semver listed as a dependency since it's being used here? https://github.com/theintern/digdug/blob/master/src/SeleniumTunnel.ts#L18
Running into an issue where
semver isn't being found https://github.com/dstaley/ssgen/pull/4/checks?check_run_id=1216741708