titan/soteria
3
0
Fork 0
Code Issues 23 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

[hermes] soteria #347: sonarqube_scan_missing_node_runtime #22

New Issue
Open
opened 2026-09-09 21:27:59 +00:00 by hermes-automation · 0 comments
hermes-automation commented 2026-09-09 21:27:59 +00:00
Member
Copy Link

Hermes auto-triage classified incident soteria/347 as sonarqube_scan_missing_node_runtime (confidence 0.76); first failed gate: sonarqube.

Why a human is needed

Build 347 failed at the 'Enforce quality gate' stage. No tests ran and none were reported failing; the only errors in the build are from the SonarQube analysis step. At 21:04:56 the scanner tried to start its JavaScript/TypeScript analysis, which launches a helper process with 'node -v', and the operating system returned 'Cannot run program "node": error=2, No such file or directory'. The resulting exception is not contained to that sensor - the stack trace reaches the scanner CLI's main method - so the analysis run aborted, no report was submitted to SonarQube, and the gate the pipeline waits on failed, ending the build with exit code 1 and skipping the image build. A second problem is visible in the same run: all 26 Go files failed to parse, one with 'Stream closed' and the rest with 'Go parser external process returned non-zero exit value: 2', which points at the bundled Go analyzer binary being unable to execute in that container (architecture mismatch or a missing native dependency) rather than at anything in the source. A fix is in the analysis environment, not in the service: install or expose Node.js in the container used for the scan (or set sonar.nodejs.executable to its path), or disable JS/TS analysis for this project if there is no JavaScript or TypeScript to inspect, and supply a Go analyzer that runs on this agent's architecture - otherwise the scan will finish but report no Go findings or coverage at all. A rebuild of the same commit will hit the identical missing binary, and the choice between provisioning Node.js and switching off JS/TS analysis is a maintainer's call, so a person needs to make the change; the retained console is truncated and the central log store was refusing connections, so nothing corroborates the Jenkins output independently.

Ariadne did not authorize automated remediation: human_required.

Facts

  • jenkins — Build 347 of job soteria ended in FAILURE, running from 2026-09-09T20:59:00Z to 2026-09-09T21:22:16Z (1395s). (https://ci.bstein.dev/job/soteria/347/ (result, timestamps))
  • jenkins — The build reported its first failed stage as 'Enforce quality gate'. (https://ci.bstein.dev/job/soteria/347/ jenkins.first_failed_stage)
  • jenkins — No structured test results were published for this build; the failed test list is empty, so no test, class, or assertion is named anywhere in the evidence. (https://ci.bstein.dev/job/soteria/347/ jenkins.failed_tests = [])
  • jenkins — At 21:04:56.806 the SonarQube scanner's TypeScript sensor failed with org.sonarsource.nodejs.NodeCommandException: "Error when running: 'node -v'. Is Node.js available during analysis?" (https://ci.bstein.dev/job/soteria/347/ console around line 316)
  • jenkins — The root cause printed for that exception is java.io.IOException: Cannot run program "node": error=2, No such file or directory, i.e. there is no node executable on the PATH of the process running the scan. (https://ci.bstein.dev/job/soteria/347/ console around line 417)
  • jenkins — That exception's stack trace propagates through org.sonarsource.scanner.cli.Main.analyze and Main.main, meaning it terminated the scanner CLI run rather than being contained to one sensor. (https://ci.bstein.dev/job/soteria/347/ console around line 417)
  • jenkins — Between 21:04:37.294 and 21:04:38.063 every Go source file in the repository failed to parse: 'internal/k8s/state.go': Stream closed, and 25 further files including cmd/soteria/main.go, internal/server/server.go and internal/longhorn/client.go with "Go parser external process returned non-zero ex... (https://ci.bstein.dev/job/soteria/347/ console around line 316)
  • jenkins — Despite those 26 parse errors the Go sensor still logged '26/26 source files have been analyzed' and completed, so the scan did not stop there. (https://ci.bstein.dev/job/soteria/347/ console around line 316)
  • jenkins — The end of the build shows 'ERROR: script returned exit code 1' and the subsequent stage 'Build & push image' skipped due to earlier failure(s); artifacts were still archived in post actions. (https://ci.bstein.dev/job/soteria/347/ console_tail, console line 3381)
  • opensearch — No centralized log records are available for the incident window 20:54:00Z-21:27:16Z: the log query failed with 'opensearch request failed: [Errno 111] Connection refused'. (log_evidence.error for incident soteria/347)

Evidence

The earliest failure region of the build console:

21:04:38.078 INFO  Sensor JaCoCo XML Report Importer [jacoco] (done) | time=12ms
21:04:38.079 INFO  Sensor IaC CloudFormation Sensor [iac]
21:04:38.243 INFO  0 source files to be analyzed
21:04:38.341 INFO  0/0 source files have been analyzed
21:04:38.342 INFO  Sensor IaC CloudFormation Sensor [iac] (done) | time=264ms
21:04:38.342 INFO  Sensor IaC Kubernetes Sensor [iac]
21:04:38.438 INFO  2 source files to be analyzed
21:04:39.402 INFO  2/2 source files have been analyzed
21:04:39.403 INFO  Sensor IaC Kubernetes Sensor [iac] (done) | time=1061ms
21:04:39.403 INFO  Sensor TypeScript analysis [javascript]
21:04:56.806 ERROR Error when running: 'node -v'. Is Node.js available during analysis?
org.sonarsource.nodejs.NodeCommandException: Error when running: 'node -v'. Is Node.js available during analysis?
	at org.sonarsource.nodejs.NodeCommand.start(NodeCommand.java:79)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.getVersion(NodeCommandBuilderImpl.java:203)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.checkNodeCompatibility(NodeCommandBuilderImpl.java:169)
	at org.sonarsource.nodejs.NodeCommandBuilderImpl.build(NodeCommandBuilderImpl.java:143)
	at org.sonar.plugins.javascri
... (truncated; the full log is in the linked build)

Inferences

  • The build did not fail on the service's Go code or its tests. Nothing compiled or ran and then reported a defect: there are no test results, no compiler diagnostics, and no assertion failures anywhere in the retained output. The only errors are from the static-analysis step itself.
  • The decisive error is that the environment running the SonarQube scan has no Node.js interpreter. The scanner's JavaScript/TypeScript sensor runs by default and starts a helper process by invoking 'node -v'; when that binary does not exist the sensor throws, and the trace shows the throw reaching...
  • Because the scan aborted, no analysis report was submitted to SonarQube, so the quality gate the pipeline waits on could never turn green. That is the most plausible chain from the scanner crash to the 'Enforce quality gate' stage failing and the script exiting 1. The roughly 17 minutes between t...
  • There is a second, independent defect in the same step: the Go analyzer's helper process exited with status 2 for all 26 Go files (and closed its stream on the first one), so not a single Go file was actually parsed. A helper binary that fails identically on every input usually means the binary c...
  • Fixing this is a change to how the analysis step is provisioned, not to the service. Either make Node.js present in the container that runs the scan (and, if it is installed somewhere non-standard, point sonar.nodejs.executable at it), or - if this repository genuinely has no JavaScript or TypeSc...
  • Re-running the same commit unchanged is not expected to help: a missing executable in the analysis image is deterministic and will reproduce on every build until the image or the scan configuration changes.

Links

Truncated by Ariadne: the diagnosis exceeded the configured issue body limit. The complete evidence bundle is in the Ariadne audit trail.

Hermes auto-triage classified incident `soteria/347` as **sonarqube_scan_missing_node_runtime** (confidence 0.76); first failed gate: `sonarqube`. ## Why a human is needed Build 347 failed at the 'Enforce quality gate' stage. No tests ran and none were reported failing; the only errors in the build are from the SonarQube analysis step. At 21:04:56 the scanner tried to start its JavaScript/TypeScript analysis, which launches a helper process with 'node -v', and the operating system returned 'Cannot run program "node": error=2, No such file or directory'. The resulting exception is not contained to that sensor - the stack trace reaches the scanner CLI's main method - so the analysis run aborted, no report was submitted to SonarQube, and the gate the pipeline waits on failed, ending the build with exit code 1 and skipping the image build. A second problem is visible in the same run: all 26 Go files failed to parse, one with 'Stream closed' and the rest with 'Go parser external process returned non-zero exit value: 2', which points at the bundled Go analyzer binary being unable to execute in that container (architecture mismatch or a missing native dependency) rather than at anything in the source. A fix is in the analysis environment, not in the service: install or expose Node.js in the container used for the scan (or set sonar.nodejs.executable to its path), or disable JS/TS analysis for this project if there is no JavaScript or TypeScript to inspect, and supply a Go analyzer that runs on this agent's architecture - otherwise the scan will finish but report no Go findings or coverage at all. A rebuild of the same commit will hit the identical missing binary, and the choice between provisioning Node.js and switching off JS/TS analysis is a maintainer's call, so a person needs to make the change; the retained console is truncated and the central log store was refusing connections, so nothing corroborates the Jenkins output independently. Ariadne did not authorize automated remediation: `human_required`. ## Facts - **jenkins** — Build 347 of job soteria ended in FAILURE, running from 2026-09-09T20:59:00Z to 2026-09-09T21:22:16Z (1395s). (`https://ci.bstein.dev/job/soteria/347/ (result, timestamps)`) - **jenkins** — The build reported its first failed stage as 'Enforce quality gate'. (`https://ci.bstein.dev/job/soteria/347/ jenkins.first_failed_stage`) - **jenkins** — No structured test results were published for this build; the failed test list is empty, so no test, class, or assertion is named anywhere in the evidence. (`https://ci.bstein.dev/job/soteria/347/ jenkins.failed_tests = []`) - **jenkins** — At 21:04:56.806 the SonarQube scanner's TypeScript sensor failed with org.sonarsource.nodejs.NodeCommandException: "Error when running: 'node -v'. Is Node.js available during analysis?" (`https://ci.bstein.dev/job/soteria/347/ console around line 316`) - **jenkins** — The root cause printed for that exception is java.io.IOException: Cannot run program "node": error=2, No such file or directory, i.e. there is no node executable on the PATH of the process running the scan. (`https://ci.bstein.dev/job/soteria/347/ console around line 417`) - **jenkins** — That exception's stack trace propagates through org.sonarsource.scanner.cli.Main.analyze and Main.main, meaning it terminated the scanner CLI run rather than being contained to one sensor. (`https://ci.bstein.dev/job/soteria/347/ console around line 417`) - **jenkins** — Between 21:04:37.294 and 21:04:38.063 every Go source file in the repository failed to parse: 'internal/k8s/state.go': Stream closed, and 25 further files including cmd/soteria/main.go, internal/server/server.go and internal/longhorn/client.go with "Go parser external process returned non-zero ex... (`https://ci.bstein.dev/job/soteria/347/ console around line 316`) - **jenkins** — Despite those 26 parse errors the Go sensor still logged '26/26 source files have been analyzed' and completed, so the scan did not stop there. (`https://ci.bstein.dev/job/soteria/347/ console around line 316`) - **jenkins** — The end of the build shows 'ERROR: script returned exit code 1' and the subsequent stage 'Build & push image' skipped due to earlier failure(s); artifacts were still archived in post actions. (`https://ci.bstein.dev/job/soteria/347/ console_tail, console line 3381`) - **opensearch** — No centralized log records are available for the incident window 20:54:00Z-21:27:16Z: the log query failed with 'opensearch request failed: [Errno 111] Connection refused'. (`log_evidence.error for incident soteria/347`) ## Evidence The earliest failure region of the build console: ``` 21:04:38.078 INFO Sensor JaCoCo XML Report Importer [jacoco] (done) | time=12ms 21:04:38.079 INFO Sensor IaC CloudFormation Sensor [iac] 21:04:38.243 INFO 0 source files to be analyzed 21:04:38.341 INFO 0/0 source files have been analyzed 21:04:38.342 INFO Sensor IaC CloudFormation Sensor [iac] (done) | time=264ms 21:04:38.342 INFO Sensor IaC Kubernetes Sensor [iac] 21:04:38.438 INFO 2 source files to be analyzed 21:04:39.402 INFO 2/2 source files have been analyzed 21:04:39.403 INFO Sensor IaC Kubernetes Sensor [iac] (done) | time=1061ms 21:04:39.403 INFO Sensor TypeScript analysis [javascript] 21:04:56.806 ERROR Error when running: 'node -v'. Is Node.js available during analysis? org.sonarsource.nodejs.NodeCommandException: Error when running: 'node -v'. Is Node.js available during analysis? at org.sonarsource.nodejs.NodeCommand.start(NodeCommand.java:79) at org.sonarsource.nodejs.NodeCommandBuilderImpl.getVersion(NodeCommandBuilderImpl.java:203) at org.sonarsource.nodejs.NodeCommandBuilderImpl.checkNodeCompatibility(NodeCommandBuilderImpl.java:169) at org.sonarsource.nodejs.NodeCommandBuilderImpl.build(NodeCommandBuilderImpl.java:143) at org.sonar.plugins.javascri ... (truncated; the full log is in the linked build) ``` ## Inferences - The build did not fail on the service's Go code or its tests. Nothing compiled or ran and then reported a defect: there are no test results, no compiler diagnostics, and no assertion failures anywhere in the retained output. The only errors are from the static-analysis step itself. - The decisive error is that the environment running the SonarQube scan has no Node.js interpreter. The scanner's JavaScript/TypeScript sensor runs by default and starts a helper process by invoking 'node -v'; when that binary does not exist the sensor throws, and the trace shows the throw reaching... - Because the scan aborted, no analysis report was submitted to SonarQube, so the quality gate the pipeline waits on could never turn green. That is the most plausible chain from the scanner crash to the 'Enforce quality gate' stage failing and the script exiting 1. The roughly 17 minutes between t... - There is a second, independent defect in the same step: the Go analyzer's helper process exited with status 2 for all 26 Go files (and closed its stream on the first one), so not a single Go file was actually parsed. A helper binary that fails identically on every input usually means the binary c... - Fixing this is a change to how the analysis step is provisioned, not to the service. Either make Node.js present in the container that runs the scan (and, if it is installed somewhere non-standard, point sonar.nodejs.executable at it), or - if this repository genuinely has no JavaScript or TypeSc... - Re-running the same commit unchanged is not expected to help: a missing executable in the analysis image is deterministic and will reproduce on every build until the image or the scan configuration changes. ## Links - Failed build: https://ci.bstein.dev/job/soteria/347/ - Full evidence bundle and audit trail li _Truncated by Ariadne: the diagnosis exceeded the configured issue body limit. The complete evidence bundle is in the Ariadne audit trail._ <!-- hermes-triage job=soteria classification=sonarqube_scan_missing_node_runtime incident=soteria/347 -->
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
atlas-reconciler bstein hermes-automation
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: titan/soteria#22
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?