Fri, 28 May 2021 09:27:18 GMT ChromeLauncher Waiting for browser.............................................................................................
Fri, 28 May 2021 09:27:19 GMT ChromeLauncher Waiting for browser...............................................................................................
Fri, 28 May 2021 09:27:19 GMT ChromeLauncher Waiting for browser.................................................................................................
Fri, 28 May 2021 09:27:20 GMT ChromeLauncher Waiting for browser...................................................................................................
Fri, 28 May 2021 09:27:20 GMT ChromeLauncher Waiting for browser.....................................................................................................
Fri, 28 May 2021 09:27:21 GMT ChromeLauncher Waiting for browser.......................................................................................................
Fri, 28 May 2021 09:27:21 GMT ChromeLauncher:error connect ECONNREFUSED 127.0.0.1:36157
Fri, 28 May 2021 09:27:21 GMT ChromeLauncher:error Logging contents of /tmp/lighthouse.mOZ6RIf/chrome-err.log
Fri, 28 May 2021 09:27:21 GMT ChromeLauncher:error Fontconfig warning: "/etc/fonts/fonts.conf", line 86: unknown element "blank"
Inconsistency detected by ld.so: ../elf/dl-tls.c: 488: _dl_allocate_tls_init: Assertion `listp->slotinfo[cnt].gen <= GL(dl_tls_generation)' failed!
Unable to connect to Chrome
370/0: Lighthouse analysis FAILED for https://website.com/en/....
rm: no such file or directory: report/lighthouse/website/en....report.json
/var/lib/jenkins/workspace/project/node_modules/lighthouse-batch/index.js:219
const score = toScore(summary.detail.performance)
TypeError: Cannot read property 'performance' of undefined
at checkBudgets (/var/lib/jenkins/workspace/project/node_modules/lighthouse-batch/index.js:219:42)
at /var/lib/jenkins/workspace/project/node_modules/lighthouse-batch/index.js:67:20
at Array.map (<anonymous>)
at execute (/var/lib/jenkins/workspace/project/node_modules/lighthouse-batch/index.js:39:38)
at Object.<anonymous> (/var/lib/jenkins/workspace/project/node_modules/lighthouse-batch/run.js:28:1)
at Module._compile (internal/modules/cjs/loader.js:1068:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
at Module.load (internal/modules/cjs/loader.js:933:32)
at Function.Module._load (internal/modules/cjs/loader.js:774:14)
at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:72:12)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! Lighthouse_Reports#1.0.0 lighthouse: `lighthouse-batch -f sites.txt -p --config-path=config.js -h --performance 75 --score 70 --no-report –chrome-flags='–headless','--no-sandbox'`
npm ERR! Exit status 1
I'm running this report for 900+ page urls.
As the logs tell, ChromeLauncher is refusing connection to Jenkins. You might want to check if Jenkins is allowed to access this running service.
This can also happen if your ChromeLauncher is not running in headless mode, or multiple instances of ChromeLauncher are running, and no available ports for it are left.
You can try adding the following to you ChromeLauncher launch configs. In fact, you should mention these.
chromeOptions = {
chromeFlags: ["--disable-gpu", "--headless", "--enable-logging"]
}
Find more details to this here.
As an alternative, you can consider running Lighthouse in a Docker instead, to isolate it from Jenkins. This way, you can scan your project, generate HTML reports and publish it back to Jenkins.
You can follow the approach mentioned here.
Related
It is my understanding that the core modules, like "fs" are part of the node.js build, and no special configuration is needed to make them available for importing, so I'm at a loss as to how "fs" could be missing when running on render.com. I have no problems building or running in development mode locally. And the service deploys and builds perfectly on render.com, but running fails with:
Jan 31 01:13:22 PM ==> Starting service with 'node index.js'
Jan 31 01:13:23 PM internal/modules/cjs/loader.js:888
Jan 31 01:13:23 PM throw err;
Jan 31 01:13:23 PM ^
Jan 31 01:13:23 PM
Jan 31 01:13:23 PM **Error: Cannot find module 'node:fs'**
Jan 31 01:13:23 PM Require stack:
Jan 31 01:13:23 PM - /opt/render/project/src/node_modules/#fastify/send/lib/SendStream.js
Jan 31 01:13:23 PM - /opt/render/project/src/node_modules/#fastify/send/index.js
Jan 31 01:13:23 PM - /opt/render/project/src/node_modules/#fastify/static/index.js
Jan 31 01:13:23 PM - /opt/render/project/src/index.js
Jan 31 01:13:23 PM at Function.Module._resolveFilename (internal/modules/cjs/loader.js:885:15)
Jan 31 01:13:23 PM at Function.Module._load (internal/modules/cjs/loader.js:730:27)
Jan 31 01:13:23 PM at Module.require (internal/modules/cjs/loader.js:957:19)
Jan 31 01:13:23 PM at require (internal/modules/cjs/helpers.js:88:18)
Jan 31 01:13:23 PM at Object.<anonymous> (/opt/render/project/src/node_modules/#fastify/send/lib/SendStream.js:10:12)
Jan 31 01:13:23 PM at Module._compile (internal/modules/cjs/loader.js:1068:30)
Jan 31 01:13:23 PM at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
Jan 31 01:13:23 PM at Module.load (internal/modules/cjs/loader.js:933:32)
Jan 31 01:13:23 PM at Function.Module._load (internal/modules/cjs/loader.js:774:14)
Jan 31 01:13:23 PM at Module.require (internal/modules/cjs/loader.js:957:19) {
Jan 31 01:13:23 PM code: 'MODULE_NOT_FOUND',
Jan 31 01:13:23 PM requireStack: [
Jan 31 01:13:23 PM '/opt/render/project/src/node_modules/#fastify/send/lib/SendStream.js',
Jan 31 01:13:23 PM '/opt/render/project/src/node_modules/#fastify/send/index.js',
Jan 31 01:13:23 PM '/opt/render/project/src/node_modules/#fastify/static/index.js',
Jan 31 01:13:23 PM '/opt/render/project/src/index.js'
Jan 31 01:13:23 PM ]
Jan 31 01:13:23 PM }
The service was running merrily along until I deployed a new version today that requires the #fastify/static package, like this:
fastify.register(require('#fastify/static'), { root: path.join(__dirname,'public'), prefix:'/public/' })
I never import "fs" directly, but #fastify/static apparently does, like this:
const statSync = require('fs').statSync
I tried importing fs explicitly before importing #fastify, but the error doesn't change. Webpack is not involved. I've tried building using both npm and yarn, no difference - not that building should affect core modules. Is there some critical environmental setup I have neglected to do on Render.com?
Ronnie's comment (thks!) made me start wondering if my assumption that "node:fs" was the same as "fs" was correct. It was not. Render.com defaults to node.js version 14.17.0. The "node:" module reference syntax was not added until a later version.
The solution was to request node version 16.0.0 on render.com using an environment variable containing the version string, and it fixed the error.
The details for specifying the version on render.com is at https://render.com/docs/node-version
An explanation of the core modules syntax is at https://nodejs.org/api/modules.html
Hi guys I try to start Docusaurus V2 as a service on ubuntu headless. Currently I have a script in my Docusaurus folder as a temporarly solution. It works when I start it with ./start.sh:
/var/www/citro-docs-2/start.sh
#!/bin/bash
npm run serve
I tried to create a service like that:
/etc/systemd/system/docusaurus.service
[Unit]
Description=Docusaurus Service
[Service]
ExecStart=/var/www/citro-docs-2/start.sh
WorkingDirectory=/var/www/citro-docs-2
[Install]
WantedBy=multi-user.target
But when I start it with sudo systemctl start docusaurus.service and check the status I get these errors:
● docusaurus.service - Docusaurus Service
Loaded: loaded (/etc/systemd/system/docusaurus.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2021-08-25 11:53:20 UTC; 4s ago
Process: 3494 ExecStart=/var/www/citro-docs-2/start.sh (code=exited, status=1/FAILURE)
Main PID: 3494 (code=exited, status=1/FAILURE)
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at require (node:internal/modules/cjs/helpers:94:18)
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Object.<anonymous> (/var/www/citro-docs-2/node_modules/#docusaurus/c>
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Module._compile (node:internal/modules/cjs/loader:1101:14)
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153>
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Module.load (node:internal/modules/cjs/loader:981:32)
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Function.Module._load (node:internal/modules/cjs/loader:822:12)
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at Function.executeUserEntryPoint [as runMain] (node:internal/modules/r>
Aug 25 11:53:20 citro-docs2 start.sh[3521]: at node:internal/main/run_main_module:17:47
Aug 25 11:53:20 citro-docs2 systemd[1]: docusaurus.service: Main process exited, code=exited, status=1/FAILURE
Aug 25 11:53:20 citro-docs2 systemd[1]: docusaurus.service: Failed with result 'exit-code'.
I found a solution where I can start the .js file directly: How do I run a node.js app as a background service? but I don't know if this is also possible for Docusaurus. At least I don't know which .js file I should start. It would be awesome if someone could help.
Yes, it is possible to run Docusaurus as a service on Ubuntu. It's important to mention that what you're trying to do here is quite normal for Node.js apps. After all, if you don't run your Node.js app as a service, then the service would stop running as soon as you close the shell you used to start the app.
However, it seems like most folks don't run Docusaurus on Ubuntu since it's "just a static site" and static sites don't really need a full blown server to run on. For example, you could leverage GitHub Pages to run your docs site.
That being said, Docusaurus is just a Node.js app. It's similar to all other Node.js apps, and you can certainly run it in Ubuntu if you wanted to.
Take a look at the docs on PM2.
The way I would start your app as a service is:
Install Node.js on your Ubuntu server (if it isn't already installed)
Install pm2 globally on your server via npm install -g pm2
Navigate to your app's directory and run npm install to install the dependencies of your app.
Now you can run pm2 start /var/www/citro-docs-2/start.sh --name myDocsSite
Your Docusaurus app should now be running. To stop it, you can run pm2 stop myDocsSite.
The first type of error occurs when I run the listener on my Windows 10 using a terminal (powershell). The listener (remixd) starts OK then when I go to connect to the browser session I get the following:
PS C:\Windows\System32> remixd -s D:\zz210201_shared_folder --remix-ide https://remix.ethereum.org
[WARN] You may now only use IDE at https://remix.ethereum.org to connect to that instance
[WARN] Any application that runs on your computer can potentially read from and write to all files in the directory.
[WARN] Symbolic links are not forwarded to Remix IDE
Wed Feb 03 2021 18:29:11 GMT+0700 (Indochina Time) Remixd is listening on 127.0.0.1:65520
setup notifications for D:\zz210201_shared_folder
Error: Error: EPERM: operation not permitted, lstat 'D:\System Volume Information'
When I use the desktop version I get the following errors when trying to make the connection.
Wed Feb 03 2021 18:13:57 GMT+0700 (Indochina Time) Remixd is listening on 127.0.0.1:65520
Wed Feb 03 2021 18:14:14 GMT+0700 (Indochina Time) Connection from origin package://6fd22d6fe5549ad4c4d8fd3ca0b7816b.mod rejected.
Wed Feb 03 2021 18:14:15 GMT+0700 (Indochina Time) Connection from origin package://6fd22d6fe5549ad4c4d8fd3ca0b7816b.mod rejected.
Wed Feb 03 2021 18:14:29 GMT+0700 (Indochina Time) Connection from origin package://6fd22d6fe5549ad4c4d8fd3ca0b7816b.mod rejected.
Wed Feb 03 2021 18:14:30 GMT+0700 (Indochina Time) Connection from origin package://6fd22d6fe5549ad4c4d8fd3ca0b7816b.mod rejected.
Wed Feb 03 2021 18:18:31 GMT+0700 (Indochina Time) Connection from origin https://remix.ethereum.org rejected.
Wed Feb 03 2021 18:18:32 GMT+0700 (Indochina Time) Connection from origin https://remix.ethereum.org rejected.
Not sure how to proceed to get it working. Any clues appreciated.
Fix Remixd EPERM error
npm uninstall -g remixd
npm install -g #remix-project/remixd --force
Apologies if some aspects of the question here are unclear as I am new to node & javascript. Please ask for further details
I have a node application that is connected to firebase using socketio. When the application is deployed on heroku, I get the following error:
Error [ERR_SERVER_ALREADY_LISTEN]: Listen method has been called more than once without closing.
Nov 01 19:57:38 app/web.1: at Server.listen (net.js:1446:11)
Nov 01 19:57:38 app/web.1: at exports.default (/app/dist/server.js:8226:11)
Nov 01 19:57:38 app/web.1: at Object.<anonymous> (/app/dist/server.js:191:21)
Nov 01 19:57:38 app/web.1: at __webpack_require__ (/app/dist/server.js:20:30)
Nov 01 19:57:38 app/web.1: at Object.<anonymous> (/app/dist/server.js:47:19)
Nov 01 19:57:38 app/web.1: at __webpack_require__ (/app/dist/server.js:20:30)
Nov 01 19:57:38 app/web.1: at /app/dist/server.js:40:18
Nov 01 19:57:38 app/web.1: at Object.<anonymous> (/app/dist/server.js:43:10)
Nov 01 19:57:38 app/web.1: at Module._compile (module.js:641:30)
Nov 01 19:57:38 app/web.1: at Object.Module._extensions..js (module.js:652:10)
Nov 01 19:57:38 app/web.1: /app/dist/server.js:212
Nov 01 19:57:38 app/web.1: throw error;
The description of the error is on this link :
https://nodejs.org/api/all.html#errors_err_server_already_listen
The listening code on my server.js is as shown:
const server = http.createServer(app).listen(port)
Any idea why this error is occurring? Should I close the server if the listen fails. If yes, how can I do it?
Thank you.
My bad. I got confused as the error was not occurring on my mac. The answer is in the error itself. The error was occurring as the listen method was being called twice. The second call was in some other module.
I have a node application that runs locally and when deploying to Nodejitsu via jitsu deploy, the CLI reports a successful deployment. However, when actually logging in to look at the application via the web based interface and attempting to activate the snapshot, the start fails with the following error:-
err Wed, 05 Nov 2014 14:10:37 GMT
err Wed, 05 Nov 2014 14:10:37 GMT module.js:340
err Wed, 05 Nov 2014 14:10:37 GMT throw err;
err Wed, 05 Nov 2014 14:10:37 GMT Error: Cannot find module '/opt/run/snapshot/package/js'
at Function.Module._resolveFilename (module.js:338:15)
at Function.Module._load (module.js:280:25)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
err Wed, 05 Nov 2014 14:10:37 GMT ^
The trouble I am having, is the vagueness of the error. What is '/opt/run/snapshot/package/js'? Is there a way of getting more detail out of Nodejitsu so I can see what maybe causing the problem? Is this something anyone else has had?
I can return to this question with more information if requested.
Help, as always, appreciated.
I solved this. The problem was in my packages.json I had the following:-
"scripts": {
"start": "js server",
"postinstall": "bower install",
"test": "make test-cov"
},
js is of course not recognised by Nodejitsu on run. I found, by changing it to:-
"scripts": {
"start": "node server.js"
},
I had no problems.
A note to future Nodejitsu deployers, postinstall runs locally -- not on the server; therefore remove bower_components from your .gitignore if you need bower components on nodejitsu.
Hope this helps any adventurers who wander by.