Now I have implemented automated testing with a puppeteer and I have packaged it and executed it.
However, after six hours, I found that the file packaged in a pkg was not running and stopped.
I used "npm pkg" to package.
Is there anyone who is talking about this issue?
add comment
:https://www.npmjs.com/package/pkg. I installed the npm pkg module after seeing this place.
I'm in the process of automated testing of a website with a puppeteer and it took me more than six hours to spin the executable file to run the test on this website.
We executed exe file by packaging code written with puppeteer using 'pkg' module.
I had a screenshot of the execution process because I was testing the website, and after six hours, I found that the screenshot was not being taken from a certain point in time.
I have already completed the unit test of my code, so I judged that there was a problem with the pkg file, not with my code or with the website.
my try:
I was setting the option for reload to waitUntil:networkidle0 I think this option is the problem. I set networkidle0 to networkidle2, and it works well. Is there anyone who knows about the difference in this?
Related
I have a rather large Vue 3 application (~550 components). It takes two minutes just to run vue-cli-service serve and around 20 seconds to re-build it after each change. Hot reload stopped working a long time ago so it always needs to be refreshed in the browser even after a small style change. Moreover, the app is still not finished and it will probably get 2-3 times this big in the next year so it will probably be even worse.
Because of these problems, I've decided to migrate it from Vue CLI to Vite. I have already resolved a lot of problems and the app seems to work with Vite now with so much better loading times.
However, it sometimes gets stuck when I start a dev server (vite command) and open it in a browser. The page keeps loading and I can see a lot of pending requests in the Network tab of Chrome DevTools. There's nothing special in the output of vite --debug and running vite --force doesn't help either.
When this problem occurs, the browser always loads a lot of modules (~900) and then it gets stuck on 10-20 modules. The status of all these HTTP requests is simply Pending and they never finish. There are no errors in the browser or on the command line.
I don't think any particular file causes this. Maybe the problem is in my deeply nested folder structure with a lot of re-exports using index.ts file on each level. It mostly gets stuck on my own modules but I've also seen cases when it was waiting for a module of some external library.
Has anybody experienced a similar problem? How did you solve it?
EDIT: I have discovered that this issue only occurs in Chromium-based browsers (Google Chrome, Brave, etc.) on Linux. It works without any problems in Chrome on MacOS and Windows as well as in other browsers (Firefox, GNOME Web, etc.) on Linux.
Thanks to this comment, I realized this was a problem with the file descriptors limit.
On Manjaro Linux (Arch-based), I was able to solve it by adding the following line to both /etc/systemd/system.conf and /etc/systemd/user.conf file:
DefaultLimitNOFILE=65536
After this change, Vite works without any problems in all browsers.
I have made a few applications (using webpack, babel, react, d3, npm etc.) that uses very similar charting code. I am in the process of splitting out that charting code into an npm package which multiple apps can then import.
To test this out, I've embedded a demo app inside my chart libraries project directory and install the library at its file path. Now, presumably i'll be able to install this in depending apps A, B and C and so on, and I can change my chart libary and all apps will reflect these changes.
The first thing I noticed is that I now have to cd into my chart library and run npm run build (which runs webpack) any time I change something, and then cd into the depending app I'm working on and run npm i. This can perhaps be improved by using npm link but there are issues there as well (such as versioning and deploying to my server). So my first question is about what a decent rapid development approach looks like now that my charting code is in a separate npm project.
The other problem I've noticed is that I've lost two valuable features with respect to my chart library code. Code completion in VSCode and debugging in chrome dev tools. I'm not sure why VSCode code completion has stopped working. And for debugging, how would i be able to debug both my depending app and the library its depending on at the same time in chrome?
I would use npm link. It's immensely helpful when working on a library and its integration side by side.
Check the Chrome settings to make sure it's not instructed to skip libraries in Settings -> Framework Blackboxing, see e.g., http://blog.edenhauser.com/tell-chrome-debugger-to-ignore-libraries/.
We are using TFS Build Tasks and one of the tasks runs npm install. This is NOT through a batch or powershell file.
It runs successfully but it looks like it completes and then hangs for about 3 to 4 minutes. I know this because the task summary says it successfully completed but it doesn't start the next task for 3 to 4 minutes.
Originally when I added the task, I don't think it would hang like this. I'm not sure what changed.
I tried using npm set progress=false, recommended from this forum and explained in this article. I haven't added npm-cache because it doesn't seem to be relevant; remember, the build task completes successfully and then hangs.
What could cause the npm task to hang after completing?
According to your description, it is make sense. NPM install is just wasting time because it takes 3-4 minutes to determine the packages are already installed.
Fist try to run you npm from the console to see the performance on TFS is normal or not. If all of your NPM tasks are taking long time, one possibility is related to nodejs version.
For instance, you are using a latest version such as nodejs (8.2.0) installed on the build agent. Then downgrade to the latest LTS (long term support) version (6.11.1) may resolve the issue for you. Details please have a look at this blog.
Another way is using npm-cache as an alternative way since you use on-premise build agents for build.
It is useful for build processes that run [npm|bower|composer|jspm]
install every time as part of their build process. Since dependencies
don't change often, this often means slower build times. npm-cache
helps alleviate this problem by caching previously installed
dependencies on the build machine. npm-cache can be a drop-in
replacement for any build script that runs [npm|bower|composer|jspm]
install.
How it Works
When you run npm-cache install [npm|bower|jspm|composer], it first
looks for package.json, bower.json, or composer.json in the current
working directory depending on which dependency manager is requested.
It then calculates the MD5 hash of the configuration file and looks
for a filed named .tar.gz in the cache directory ($HOME/.package_cache
by default). If the file does not exist, npm-cache uses the system's
installed dependency manager to install the dependencies. Once the
dependencies are installed, npm-cache tars the newly downloaded
dependencies and stores them in the cache directory. The next time
npm-cache runs and sees the same config file, it will find the tarball
in the cache directory and untar the dependencies in the current
working directory.
A sample for your reference: Speed up your npm dependent CI build
I am using version 4.5.5 of jhipster.
My OS is Linux Mint.
I am using IntelliJ as my IDE.
Everything is working fine in terms of generating the code, building and running the code.
Client
Unfortunately, when I make changes to the client code (html or ts), the changes are not reflected until I recompile the client code completed. To achieve this I do "mvn -Pdev,webpack". It takes quite a while to restart the client and this is really holding me back.
Hot Deploy
What I expect to happen is that I can run "npm start" and when I save a change to a ts or a html file that it will be picked up and the change immediately visible in the browser.
Questions
Any ideas why the client hot deploy is not working ?
Any ideas how I identify where the issue is ?
For example, how do I know what folders are being watched by the hot deploy ?
Thanks a million for you help.
I am sure others have encountered the same issue and will read the answer gladly.
Kind regards,
Fergal.
PS Need any details, simply ask.
Figured it out.
Somebody else had a similar issue with a globally installed instance of webpack.
I installed a local version and the file updates are being detected and recompiled and the app hot deployed. Now working perfectly.
To install a local version webpack.js.org/guides/installation/#local-installation.
We have e2e test integrated with Jenkins system. For a few weeks this test successfully ran both, locally and from Jenkins (as a part of the build pipeline).
At the end of Sprint, I modified the script to reflect Sprint changes and made sure it passed locally. Then, I merged the changes with master. Now, e2e runs from Jenkins are failing 100% of the time, while when I locally connect to QA envs there is no problem.
The error I am getting is - Element is not clickable at point (x, y) which I cannot reproduce locally.
The server doesn't have a real screen so I cannot go out there and see what's going on. Resolutions are perfectly matching. I have other people running this test locally and there is no problem.
What could possibly cause these failures and how do I troubleshoot this problem?
Thanks for your help!
Its a question from 1000ft and pretty difficult to identify where exactly the issue could be but I listed down some probable causes/debugging tips that could help you
1.Whats your checkout strategy from source code repository? Check job workspace and it should have the most recent code and check if its indeed the latest one.
May be configure Job to always pick a new version instead of 'update'
2.Add a reporter based on the test framework you are using especially the ones which provide screenshots. Refer my blog for more details -
3.Check the stack trace of your error from Jenkins console report and verify the exact trigerring point