codymikol / karma-webpack

Karma webpack Middleware

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Running 2 karma instances with karma-webpack v5 does not seem to be supported

nicojs opened this issue · comments

  • Operating System: Both Windows and Ubuntu
  • Node Version: 14
  • NPM Version: 6.14
  • webpack Version: 4.41
  • karma-webpack Version: 4.0.2
  • karma: 6.0.0

Expected Behavior

I should be able to run multiple karma instances with karma-webpack in parallel.

Actual Behavior

Karma-webpack v5.alpha-5 doesn't seem to support running multiple builds in parallel, at least not using the alternative usage from the readme.

See KarmaWebpackController, the output path is hardcoded to be path.join(os.tmpdir(), '_karma_webpack_'). Which would interfere with other instances of karma-webpack v5.

https://github.com/ryanclark/karma-webpack/blob/4fe1f6093fc6ff25503f1422123b2b3944a4145a/lib/KarmaWebpackController.js#L41-L43

I think the easy solution would be to postfix a random number at the end of the directory as karma does.

How Do We Reproduce?

Run 2 instances of karma in 2 different karma-webpack projects.

I've noticed this when I saw an error for 'directory already exists' when I ran 2 instances of karma-webpack in parallel. I think that had to do with these lines of code:

https://github.com/ryanclark/karma-webpack/blob/8d7366f3cb747a9493c9f5542b9cb0317ac32d9e/lib/karma-webpack.js#L17-L19

The race condition would be that the 2 instances ran into the if statement simultaneously, which causes this error in 1 of the 2.

I'll be able to take a look at this on Monday

I temporarily workarounded this by adding this code to my karma config file:

const fs = require("fs");
const os = require('os')

const patchedTempDir = path.join(os.tmpdir(), Math.floor(Math.random() * 1000000));
if (!fs.existsSync(patchedTempDir)){
    fs.mkdirSync(patchedTempDir);
}
// different env vars for different OS
process.env.TMPDIR = patchedTempDir;
process.env.TMP = patchedTempDir;
process.env.TEMP = patchedTempDir;

I was able to reproduce this in a test, it looks like one test suite works and the others just return nothing. It also like chrome is signaled to shut down.

Process ChromeHeadless exited with code null and signal SIGTERM

I'll see if we can cut another version soon, I believe this should be fixed now with your suggestion to postfix a number.

This should now work in the alpha.6 version

Just tested - work well in my env (9 parallel processes)