[hermes] soteria #1138: sonarqube_scanner_environment_failure #67

Open
opened 2026-09-29 18:47:16 +00:00 by hermes-automation · 0 comments

Hermes auto-triage classified incident soteria/1138 as sonarqube_scanner_environment_failure (confidence 0.55); first failed gate: Enforce quality gate.

Why a human is needed

The 'Enforce quality gate' stage failed before the image build stage ever ran. Inside that stage, the SonarQube scan hit two separate problems: its Go analyzer's parser subprocess reported 'Stream closed' and 'non-zero exit value: 2' for all 26 .go files it touched (even though the sensor claims it finished analyzing them), and separately its TypeScript/JavaScript sensor could not find a Node.js executable at all ('node: No such file or directory') — not a version mismatch, the binary simply isn't present. That points to the build image/container this scan runs in being missing Node.js, and possibly having an unhealthy Go-parser helper process as well. The captured console output doesn't reach far enough to show the scanner's own exit status or the quality gate's actual pass/fail metrics, so it isn't yet certain whether the stage failed purely because the scanner errored out or because a real code-quality metric failed afterward. A fix would involve confirming Node.js is installed in whatever agent/container image runs this scan stage (and checking why the Go parser subprocess is failing there), then re-running to see whether the quality gate itself passes once the environment is corrected. If this project genuinely doesn't need JavaScript/TypeScript analysis, disabling those SonarQube sensors for it would also sidestep the missing-node error.

Ariadne did not authorize automated remediation: human_required.

Facts

  • jenkins — Build soteria/1138 finished with result FAILURE and Jenkins reports first_failed_stage as 'Enforce quality gate'. (jenkins.result, jenkins.first_failed_stage)
  • jenkins — No structured test results were published for this build (jenkins.failed_tests is empty). (jenkins.failed_tests)
  • jenkins — The SonarQube Go analyzer logged 26 'Cannot parse' errors while analyzing files under internal/k8s, internal/config, internal/api, internal/server, internal/longhorn, and cmd/soteria, citing 'Stream closed' and 'Go parser external process returned non-zero exit value: 2', though it still reported... (jenkins.console_failures[0] (marker 'non-zero exit', line 304))
  • jenkins — The SonarQube TypeScript/JavaScript sensor threw NodeCommandException: "Error when running: 'node -v'. Is Node.js available during analysis?" with root cause java.io.IOException: Cannot run program "node": error=2, No such file or directory. (jenkins.console_failures[1] (marker 'No such file', line 405))
  • jenkins — The pipeline's 'Build & push image' stage was skipped due to the earlier failure, and the pipeline ended with 'ERROR: script returned exit code 1' and overall result FAILURE. (jenkins.console_tail)
  • opensearch — OpenSearch log correlation for this incident window returned no records because the query failed with 'Connection refused'. (log_evidence.error)

Evidence

The earliest failure region of the build console:

18:04:44.023 INFO  Sensor JaCoCo XML Report Importer [jacoco] (done) | time=8ms
18:04:44.023 INFO  Sensor IaC CloudFormation Sensor [iac]
18:04:44.122 INFO  0 source files to be analyzed
18:04:44.200 INFO  0/0 source files have been analyzed
18:04:44.201 INFO  Sensor IaC CloudFormation Sensor [iac] (done) | time=178ms
18:04:44.201 INFO  Sensor IaC Kubernetes Sensor [iac]
18:04:44.238 INFO  2 source files to be analyzed
18:04:44.699 INFO  2/2 source files have been analyzed
18:04:44.699 INFO  Sensor IaC Kubernetes Sensor [iac] (done) | time=498ms
18:04:44.700 INFO  Sensor TypeScript analysis [javascript]
18:04:54.708 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.javascript
... (truncated; the full log is in the linked build)

Inferences

  • The quality gate stage most likely failed because the SonarQube scan environment is missing the Node.js binary needed for its JavaScript/TypeScript sensor, and/or because its Go source parser subprocess is unhealthy in this environment (Stream closed / exit value 2 for every .go file) — both poin...
  • Because jenkins.console is truncated and console_tail only shows Jenkins' post-actions (artifact archiving, pipeline teardown), it isn't possible from this bundle alone to confirm whether the stage's exit code 1 came directly from the scanner raising these errors or from an actual quality-gate me...
  • The OpenSearch connection failure only means structured log evidence could not be retrieved for this window; it does not itself explain or contribute to the Jenkins failure.

Suggested remediation (not available)

No automated remediation exists for this failure. Hermes proposes one; it was not performed, and Ariadne cannot perform it until a person builds and deploys it.

  • Proposed action: ensure_node_runtime_in_sonar_scan_image
  • What it would do: Verify, and install if missing, a Node.js runtime in the Jenkins agent/container image used for the SonarQube scan stage before invoking sonar-scanner, since its JS/TS sensor unconditionally shells out to 'node -v' even when there is nothing to analyze.
  • Evidence that should be required first: Console output showing a NodeCommandException / 'Cannot run program "node"... No such file or directory' during a SonarQube scan stage.
  • Failed build: https://ci.bstein.dev/job/soteria/1138/
  • Full evidence bundle and audit trail live in Ariadne at /api/admin/audit/events, event types hermes_autotriage_incident and hermes_autotriage_diagnosis.

Filed automatically by Ariadne from a Hermes Agent diagnosis (run run_265fbc9ea72847cd9c062b4fac5699bd). Hermes has no write access to this repository; no files or infrastructure were changed.

Hermes auto-triage classified incident `soteria/1138` as **sonarqube_scanner_environment_failure** (confidence 0.55); first failed gate: `Enforce quality gate`. ## Why a human is needed The 'Enforce quality gate' stage failed before the image build stage ever ran. Inside that stage, the SonarQube scan hit two separate problems: its Go analyzer's parser subprocess reported 'Stream closed' and 'non-zero exit value: 2' for all 26 .go files it touched (even though the sensor claims it finished analyzing them), and separately its TypeScript/JavaScript sensor could not find a Node.js executable at all ('node: No such file or directory') — not a version mismatch, the binary simply isn't present. That points to the build image/container this scan runs in being missing Node.js, and possibly having an unhealthy Go-parser helper process as well. The captured console output doesn't reach far enough to show the scanner's own exit status or the quality gate's actual pass/fail metrics, so it isn't yet certain whether the stage failed purely because the scanner errored out or because a real code-quality metric failed afterward. A fix would involve confirming Node.js is installed in whatever agent/container image runs this scan stage (and checking why the Go parser subprocess is failing there), then re-running to see whether the quality gate itself passes once the environment is corrected. If this project genuinely doesn't need JavaScript/TypeScript analysis, disabling those SonarQube sensors for it would also sidestep the missing-node error. Ariadne did not authorize automated remediation: `human_required`. ## Facts - **jenkins** — Build soteria/1138 finished with result FAILURE and Jenkins reports first_failed_stage as 'Enforce quality gate'. (`jenkins.result, jenkins.first_failed_stage`) - **jenkins** — No structured test results were published for this build (jenkins.failed_tests is empty). (`jenkins.failed_tests`) - **jenkins** — The SonarQube Go analyzer logged 26 'Cannot parse' errors while analyzing files under internal/k8s, internal/config, internal/api, internal/server, internal/longhorn, and cmd/soteria, citing 'Stream closed' and 'Go parser external process returned non-zero exit value: 2', though it still reported... (`jenkins.console_failures[0] (marker 'non-zero exit', line 304)`) - **jenkins** — The SonarQube TypeScript/JavaScript sensor threw NodeCommandException: "Error when running: 'node -v'. Is Node.js available during analysis?" with root cause java.io.IOException: Cannot run program "node": error=2, No such file or directory. (`jenkins.console_failures[1] (marker 'No such file', line 405)`) - **jenkins** — The pipeline's 'Build & push image' stage was skipped due to the earlier failure, and the pipeline ended with 'ERROR: script returned exit code 1' and overall result FAILURE. (`jenkins.console_tail`) - **opensearch** — OpenSearch log correlation for this incident window returned no records because the query failed with 'Connection refused'. (`log_evidence.error`) ## Evidence The earliest failure region of the build console: ``` 18:04:44.023 INFO Sensor JaCoCo XML Report Importer [jacoco] (done) | time=8ms 18:04:44.023 INFO Sensor IaC CloudFormation Sensor [iac] 18:04:44.122 INFO 0 source files to be analyzed 18:04:44.200 INFO 0/0 source files have been analyzed 18:04:44.201 INFO Sensor IaC CloudFormation Sensor [iac] (done) | time=178ms 18:04:44.201 INFO Sensor IaC Kubernetes Sensor [iac] 18:04:44.238 INFO 2 source files to be analyzed 18:04:44.699 INFO 2/2 source files have been analyzed 18:04:44.699 INFO Sensor IaC Kubernetes Sensor [iac] (done) | time=498ms 18:04:44.700 INFO Sensor TypeScript analysis [javascript] 18:04:54.708 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.javascript ... (truncated; the full log is in the linked build) ``` ## Inferences - The quality gate stage most likely failed because the SonarQube scan environment is missing the Node.js binary needed for its JavaScript/TypeScript sensor, and/or because its Go source parser subprocess is unhealthy in this environment (Stream closed / exit value 2 for every .go file) — both poin... - Because jenkins.console is truncated and console_tail only shows Jenkins' post-actions (artifact archiving, pipeline teardown), it isn't possible from this bundle alone to confirm whether the stage's exit code 1 came directly from the scanner raising these errors or from an actual quality-gate me... - The OpenSearch connection failure only means structured log evidence could not be retrieved for this window; it does not itself explain or contribute to the Jenkins failure. ## Suggested remediation (not available) No automated remediation exists for this failure. Hermes proposes one; it was not performed, and Ariadne cannot perform it until a person builds and deploys it. - Proposed action: `ensure_node_runtime_in_sonar_scan_image` - What it would do: Verify, and install if missing, a Node.js runtime in the Jenkins agent/container image used for the SonarQube scan stage before invoking sonar-scanner, since its JS/TS sensor unconditionally shells out to 'node -v' even when there is nothing to analyze. - Evidence that should be required first: Console output showing a NodeCommandException / 'Cannot run program "node"... No such file or directory' during a SonarQube scan stage. ## Links - Failed build: https://ci.bstein.dev/job/soteria/1138/ - Full evidence bundle and audit trail live in Ariadne at `/api/admin/audit/events`, event types `hermes_autotriage_incident` and `hermes_autotriage_diagnosis`. Filed automatically by Ariadne from a Hermes Agent diagnosis (run [run_265fbc9ea72847cd9c062b4fac5699bd](https://triage.bstein.dev/chat?resume=run_265fbc9ea72847cd9c062b4fac5699bd)). Hermes has no write access to this repository; no files or infrastructure were changed. <!-- hermes-triage job=soteria classification=sonarqube_scanner_environment_failure incident=soteria/1138 -->
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: titan/soteria#67
No description provided.