Errors while running CI Bitbucket Cloud, no changes on our side.
We only have backend java code - no Node.js as usual - , the scanner command hasn’t changed for a while:
We get these errors: [ERROR] /root/.sonar/js/node-runtime/node: /lib64/libm.so.6: version GLIBC_2.27' not found (required by /root/.sonar/js/node-runtime/node)*** ***[ERROR] /root/.sonar/js/node-runtime/node: /lib64/libc.so.6: version GLIBC_2.28’ not found (required by /root/.sonar/js/node-runtime/node) [WARNING] Embedded Node.js failed to deploy. Will fallback to host Node.js. org.sonar.plugins.javascript.nodejs.NodeCommandException: Failed to determine the version of Node.js, exit value 1. Executed: ‘/root/.sonar/js/node-runtime/node -v’ [ERROR] Error when running: ‘node -v’. Is Node.js available during analysis?
***org.sonar.plugins.javascript.nodejs.NodeCommandException: Error when running: ‘node -v’. *** Is Node.js available during analysis?
We have never had Node.js on this java repository.
I can see some people have the same issue 13 days ago and they required a fix from SonarCloud team.
As announced in December, the Sonar analysis now requires a Node.js runtime. This results in a hard fail, if your project has files that are analyzed by the JS/TS analyzer and no compatible Node.js runtime, is available.
To mitigate this issue, we have embedded Node.js runtimes for Linux x64, Windows x64, and MacOS ARM64, but there are some platforms that we don’t support such as Linux Alpine.
The fix suggested does not work for us , since wevare triggering the sonar scanner from BitBucket pipeline ,so we need to have Bitbucket Pipe running the correct version of sonarcloud scanner. I found this in Sonar cloud documentation :
Bitbucket Pipelines
(Scanner environment & SonarCloud)
Version 2.0.0 and onward of the sonarcloud-scan Bitbucket Pipe uses the required version of Node.js. You should ensure that you specify at least version 2.0.0 of the pipe declaration in your bitbucket-pipelines.yml. For example:
pipe: sonarsource/sonarcloud-scan:2.0.0
I tried the above and it causes other issues because then , we bypass the sonar properties that we have in pom.xml , which we pass with command mvn -B sonar:sonar -Dsonar…
If we adopt - pipe: sonarsource/sonarcloud-scan:2.0.0, can we pass the sonar properties using a property file such as .sonarcloud.properties? Is this the file name that we need to use ?
If you simply try to update your scanner version (1) as you did, what do you get?
- pipe: sonarsource/sonarcloud-scan:2.0.0
If this leads to an OOM issue, could you try to add this option to raise the amount of RAM available for the Node.js process in the analyzer (2), as it was proposed in this thread:
If the issue persists, could you join your log files here?
I tried the above and it causes other issues because then , we bypass the sonar properties that we have in pom.xml , which we pass with command mvn -B sonar:sonar -Dsonar…
You mean that trying (1) led to some issues with your Maven scan job?
If we adopt - pipe: sonarsource/sonarcloud-scan:2.0.0, can we pass the sonar properties using a property file such as .sonarcloud.properties? Is this the file name that we need to use ?
You can pass them in EXTRA_ARGS as shown in (2). Would that fit?
But we have some concern because in other part of the documentation says that we should no use pipe commands with maven projects - even though it runs fine for our maven projects -
They are ignored as mvn -B verify sonar:sonar … is not run , but it is ok if they are provided in sonar-project.properties. Properties are read from property file when the sonar step is run
I am facing the same problem that is mentioned here. And we have Ubuntu 18.04 locked build agents that we cannot upgrade to install the latest version of node.
We are on Sonarqube server version 10.6 and using “sonar-scanner-cli-6.1.0.4477-linux-x64” scanner for the project that have python and js/ts source code.
For some reason using the embedded version of Node is also failing. Is there any option to force scanner to use embedded version ?
Also is there any work around for us to scan JS/TS code without upgrading node and Ubuntu OS?
Thanks for looking into this issue.
The scanning is done through Teamcity. I could not attach the full log of the run as it has some confidential info. So I am attaching only the relavant part of failure after replacing project names, users etc.
Thank you for the logs, the following lines are relevant. You can see that the analyzer failed to unpack the embedded Node.js runtime: Embedded Node.js failed to deploy
This could happen if the analyzer is trying to write in a folder where it does not have the necessary permissions. You can change it by defining the SONAR_USER_HOME env variable or sonar.userHome parameter.
By default, it’s trying to unpack it in ~/.sonar/.
Here is the reference documentation page.
[14:22:33][Step 24/31] 14:22:33.721 INFO Sensor JavaScript/TypeScript analysis [javascript]
[14:22:34][Step 24/31] 14:22:34.592 INFO Detected os: Linux arch: amd64 alpine: false. Platform: LINUX_X64
[14:22:34][Step 24/31] 14:22:34.603 ERROR /home/user/.sonar/js/node-runtime/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/user/.sonar/js/node-runtime/node)
[14:22:34][Step 24/31] 14:22:34.606 WARN Embedded Node.js failed to deploy. Will fallback to host Node.js.
[14:22:34][Step 24/31] org.sonar.plugins.javascript.nodejs.NodeCommandException: Failed to determine the version of Node.js, exit value 1. Executed: '/home/user/.sonar/js/node-runtime/node -v'
[14:22:34][Step 24/31] at org.sonar.plugins.javascript.nodejs.NodeVersion.getVersion(NodeVersion.java:59)
[14:22:34][Step 24/31] at org.sonar.plugins.javascript.bridge.EmbeddedNode.deploy(EmbeddedNode.java:195)
[14:22:34][Step 24/31] at org.sonar.plugins.javascript.bridge.BridgeServerImpl.deploy(BridgeServerImpl.java:174)
[14:22:34][Step 24/31] at org.sonar.plugins.javascript.bridge.BridgeServerImpl.startServerLazily(BridgeServerImpl.java:297)
[14:22:34][Step 24/31] at org.sonar.plugins.javascript.bridge.AbstractBridgeSensor.execute(AbstractBridgeSensor.java:73)
[14:22:34][Step 24/31] at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
[14:22:34][Step 24/31] at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
[14:22:34][Step 24/31] at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:61)
[14:22:34][Step 24/31] at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:79)
[14:22:34][Step 24/31] at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:61)
[14:22:34][Step 24/31] at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
[14:22:34][Step 24/31] at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:204)
[14:22:34][Step 24/31] at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:200)
[14:22:34][Step 24/31] at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:173)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
[14:22:34][Step 24/31] at org.sonar.scanner.bootstrap.SpringScannerContainer.doAfterStart(SpringScannerContainer.java:351)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
[14:22:34][Step 24/31] at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:144)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:226)
[14:22:34][Step 24/31] at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:205)
[14:22:34][Step 24/31] at org.sonar.scanner.bootstrap.ScannerMain.runScannerEngine(ScannerMain.java:149)
[14:22:34][Step 24/31] at org.sonar.scanner.bootstrap.ScannerMain.run(ScannerMain.java:66)
[14:22:34][Step 24/31] at org.sonar.scanner.bootstrap.ScannerMain.main(ScannerMain.java:52)
I would like to note that it’s weird that it tried to execute the embedded runtime after failing to deploy: Executed: '/home/user/.sonar/js/node-runtime/node -v', and will investigate this. But this shouldn’t bother you.
