Version SonarQube: Community 8.3.1 build 34397
Version Scanner: sonar-scanner-18.104.22.1682-windows
- This is a small proof-of-principal nodejs project
** 10 - 15 files files < 100 lines
- I would like the analysis to be somewhat timely (it takes 3 - 4 minutes which is too long)
What I have achieved
- Installed the sonar server, and scanner, set up my path and run successful scans and find code issues and quality gates fail when appropriate.
Additional Details (problem/question)
- I run the sonar-scanner.bat in verbose mode
- Each time I run I see: Deploying eslint-bridge into /.scannerwork/.sonartmp/eslint-bridge-bundle
- How do I not have sonar-scanner do this every single time (or at all)?
- This takes a HUGE amount of time and always does this during sonar-scanner runs
- I installed eslint and eslint-plugin-sonarjs using npm and set up my .eslintrc to see if that would help (globally), but no go
I do notice this in the output of my scanner:
14:43:16.226 DEBUG: ‘SonarJS Coverage’ skipped because one of the required properties is missing
14:43:16.226 DEBUG: ‘Import of ESLint issues’ skipped because one of the required properties is missing
Here are the logs centered around the call to deploy eslint-bridge
14:43:16.233 INFO: Sensor SonarCSS Rules [cssfamily]
14:43:16.234 INFO: No CSS, PHP, HTML or VueJS files are found in the project. CSS analysis is skipped.
14:43:16.234 INFO: Sensor SonarCSS Rules [cssfamily] (done) | time=1ms
14:43:16.234 INFO: Sensor JaCoCo XML Report Importer [jacoco]
14:43:16.236 INFO: ‘sonar.coverage.jacoco.xmlReportPaths’ is not defined. Using default locations: target/site/jacoco/jacoco.xml,target/site/jacoco-it/jacoco.xml,build/reports/jacoco/test/jacocoTestReport.xml
14:43:16.237 INFO: No report imported, no coverage information will be imported by JaCoCo XML Report Importer
14:43:16.237 INFO: Sensor JaCoCo XML Report Importer [jacoco] (done) | time=3ms
14:43:16.237 DEBUG: Deploying bundle
14:43:16.237 DEBUG: Deploying eslint-bridge into C:\my-project-home.scannerwork.sonartmp\eslint-bridge-bundle
14:46:14.763 DEBUG: Deploying bundle (done) | time=178525ms
14:46:14.763 DEBUG: Starting server
14:46:14.781 DEBUG: Using default Node.js executable: ‘node’.
14:46:14.781 DEBUG: Checking Node.js version
14:46:14.783 DEBUG: Launching command node -v
14:46:15.193 DEBUG: Using Node.js v12.14.1.
14:46:15.193 DEBUG: Starting Node.js process to start eslint-bridge server at port 58002
17:00:21.448 DEBUG: Deploying eslint-bridge into /Users/jeffzapotoczny/sonarsrc/sonar-training-examples/angular/.scannerwork/.sonartmp/eslint-bridge-bundle
17:00:22.870 DEBUG: Deploying bundle (done) | time=1422ms
It’s fairly speedy for me, on a MacBook Pro laptop. Can you comment on the hardware & disk you’re using (SSD or something older?). Is it an older machine or happening in some kind of CI context?
Thank you for the response and looking into this. I run a fairly decent laptop: 6 cores, 12 threads, 2-3.5 ghz (boost) 16 gigs of ram, ssd, etc… All is in order there, nothing getting close to memory or cpu limits.
Yes, I am running in a CI context, doing a proof-of-principal with Bamboo and Sonar. Is there an additional task I have to do in order to speed things along? I am following when bamboo is calling the sonar-scanner.bat. In my logs, looking almost the same as yours–except for the speed, I see 3.5 minutes. But, yeah, how come yours is flying by at 1.5 secs?
Yup, understand that an eslint scanner as a node process is non-negotiable.
Out of curiosity, why deploy an eslint node server each and every time, seems maybe inefficient, right? Why not put in the configuration, somewhere, the ability to use an already existing eslint node app, wherever. Right now it’s baked into your code to first deploy the node app and then to scan. Why not first check a config and then if the eslint process/server responds use that one, or deploy. I suppose those little processes could add up.
Thank you again!
Jeff, any advice on reducing time to deploy eslint node server in a CI environment?
I haven’t responded because I don’t have any further suggestions on this issue; perhaps a member of our languages team might come along with some deeper troubleshooting suggestions.
Jeff, so why did you ask if I was running this in a CI environment? Would that be a reason for the slowdown?
Regardless, thank you for the help… I’ll try this on our normal deployed environment, it’s probably fine.
My earlier question about a CI environment was simply to contrast the possibility that you might be running this on an underpowered machine with the hope that it would perform better on something with more power/faster disk. There’s nothing magical that I know of about any CI platform in terms of this specific issue.
Indeed, I think the idea of simply trying it in the environment where you normally conduct builds makes perfect sense.
poor IO performance on Windows can be caused by anti-virus scanning every file while unpacking the bundle. Can you try to temporarily turn off any antivirus solution you might be using if it improves the performance? Also, are you running this setup in any sort of virtualized environment? This can also impact negatively IO performance.
We are considering the idea to cache the extracted bundle, however so far it was not a priority for us as it increases the complexity of the startup, because we need to also verify integrity and version of the cached bundle.
Thank you very much, yes, I am running antivirus software, or to be more accurate, antivirus software is running. I have no control over this process and my employers would take a dim view of me for turning this functionality off. Certainly on the server where this is intended to run (linux) there would be limited antivirus software and we have greater control.
Thank you for the tip!
I think it’s a great idea to cache the bundle. Possibly even provide a configuration option to provide a running instance of the eslint-bridge for users like myself. This would avoid the complexity of caching.