-
Notifications
You must be signed in to change notification settings - Fork 12k
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
Chrome/karma is started before the webpack dev server is ready to serve #22495
Comments
In this case you can configure and increase Karma's In the Angular CLI, Karma is initialized prior to Webpack. The rational for this is that Webpack needs to run in Karma context in order for it to notify Karma about file changes and complication errors. |
The problem is not Karma waiting long enough, the problem is that chrome itself gives up. Karma has a bug as mentioned that many reports will not work when this happens. As a result, changing any timeouts has no effect on the issue. This is currently really breaking us as all our code coverage metrics in our branch builds for PRs fail due to no coverage reports being generated. That is why we are requesting that karma not be started until after the webpack has started. I'd LOVE to get rid of webpack since it is extremely slow, but this would be a temporary fix |
I am a bit confused when you say Chrome itself gives up, the logs in karma-runner/karma#3745 (pasted below), show that actually Karma terminated Chrome because the capture timeout has elapsed (
I tried to replicate this locally and I did a couple of things. I firstly forcefully slowed down the build to take I then, increased the
Based on the comments this should have not have generated a coverage report, but in my case it did 😑. Then, I tried to increase
In the later case, from the logs we see that Chrome was not killed and again the coverage report was generated. |
I'll try tweaking our karma settings and see if that helps and I'll report back. |
Increasing the timeout just makes it longer before chrome is killed. The process just "hangs" here now until the timeout is reached:
As mentioned, I believe the issue to be that chrome gave up trying to load the page since webpack is such a slow beast. As you can see, webpack is taking 216 seconds to bring up the server. |
11 minutes in and the test still have not started, so increasing the timeout is making the issue worse, not better, unfortunately:
|
Can you please share your karma configuration? |
Let it go for a long time, and it eventually started the tests:
karma.coverage.ts:
and karma.ts:
|
Looking at output again and I noticed is that after the bundle generation is complete at
From the logs of a previous post I also noticed some ping timeouts and these are all post the bundle is generated and Karma server is read to take on requests.
I wonder if bundle sizes and the fact that coverage is enabled (which incurs additional XHR requests) are actually overloading the Karma dev-server. I did try your config locally, but I was still unable to replicate the issue when I slow down the build to
Forgot to mention this in my previous post, but for Karma, we actually don't use webpack-dev-server. We use Karma's own dev-server, so the setup is more of Karma invokes Webpack to generate the bundle. Karma waits for Webpack to finish generating the bundle prior to doing any requests, such requests will be redirect to Webpack through an additional middleware. I do see ways to run Webpack and wait for it to finish prior to invoking Karma, but this would likely require a number of major changes. Does this happen in local environments or only in CI?, Do you have caching disabled? |
Has this been addressed through karma-runner/karma-coverage#434 (comment)? |
@alan-agius4 - no I don't believe it is a fix We finally got some improvement by using the code in this comment: I only had to tweak the code for webpack 5 (afterDone to done for example). Our builds seem more stable, but we just made the change. The work-around causes karma to not start the tests/browser until webpack issues a done compilation callback. |
@arobinson, thanks for sharing that. That is interesting approach. I think we should be able to integrate that in our Karma plugin quite easily. |
…uild is complete This change is inspired by karma-runner/karma-chrome-launcher#154 (comment) which blocks Karma from launching the browsers until the compilation is complete. This is needed especially for large applications when using code-coverage where otherwise the users would have to fine-tune several Karma timeouts such as `captureTimeout` for various environments. Closes #22495 (cherry picked from commit 7ce5000)
…uild is complete This change is inspired by karma-runner/karma-chrome-launcher#154 (comment) which blocks Karma from launching the browsers until the compilation is complete. This is needed especially for large applications when using code-coverage where otherwise the users would have to fine-tune several Karma timeouts such as `captureTimeout` for various environments. Closes #22495
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🐞 Bug report
Command (mark with an
x
)Is this a regression?
Yes, the previous version in which this bug was not present was: ....No, AFAIK, this has always been present
Description
A clear and concise description of the problem...There is this issue in Karma: karma-runner/karma#3745
What happens is that Angular CLI is starting karma and the webpack dev server at the same time. On large Angular projects, like ours, Angular + webpack is very slow (1-2 minutes to start
ng serve
for example, separate issue we really need to address somehow).What seems to occur is that chrome (or ChromeHeadless) gives up trying to load the page (it would see the problem that the server is not responding). Karma then kills the browser and restarts it (triggering issue karma-runner/karma#3745). Eventually the webpack dev server starts responding, and the tests run. Once the tests complete, the coverage report (and potentially other reporters) fail to write their reports.
While there is a bug in Karma that needs to be fixed, it does not seem to make sense to start the test framework until the webpack dev server is ready to serve the application. When it is ready, we see the
Browser application bundle generation complete
printed to the terminal.Ideally karma would be started after a 200 HTTP response could be obtained from the webpack dev server
🔬 Minimal Reproduction
Only thing that is required is to run
ng test
on an Angular project. The problem to reproduce is that the application has to have enough code to cause webpack dev server to be too slow to start before chrome gives up loading the page.🔥 Exception or Error
🌍 Your Environment
Anything else relevant?
The text was updated successfully, but these errors were encountered: