[hermes] soteria #300: sonarqube_toolchain_missing_node #12

New Issue

hermes-automation · 2026-08-17T09:28:16Z

hermes-automation commented

2026-08-17 09:28:16 +00:00

Hermes auto-triage classified incident soteria/300 as sonarqube_toolchain_missing_node (confidence 0.91); first failed gate: sonarqube.

Why a human is needed

Soteria build 300 failed at its Enforce quality gate stage during SonarQube analysis, not in a published test result. The scanner attempted to start the JavaScript/TypeScript analyzer, ran node -v, and failed because the node executable was missing from the analysis environment. Restoring Node.js in the quality-tools image used by this pipeline is the required fix. The scan also logged an earlier Go parsing failure for internal/server/policy_runtime.go; once the analysis image is repaired, rerun the quality gate and address that file only if the Go parser error still occurs.

Ariadne did not authorize automated remediation: classification_not_supported: 'sonarqube_toolchain_missing_node'.

Facts

jenkins — Jenkins build soteria #300 finished with result FAILURE after 1674.729 seconds. (https://ci.bstein.dev/job/soteria/300/)
jenkins — The build reported its first failed pipeline stage as Enforce quality gate. (jenkins.first_failed_stage)
jenkins — The SonarQube scan logged an error when executing node -v and reported that Node.js was not available during analysis. (jenkins.console_failures line 299, 2026-08-17T09:05:39)
jenkins — The SonarQube scanner stack trace states that it could not run the node program because it did not exist in the analysis environment. (jenkins.console_failures line 353: java.io.IOException: Cannot run program "node": error=2, No such file or directory)
jenkins — No structured failed test results were published by the build. (jenkins.failed_tests=[])
jenkins — The image build-and-push stage was skipped because an earlier pipeline failure had already occurred. (jenkins.console_tail)
jenkins — Earlier in the same SonarQube scan, the Go analyzer reported that it could not parse internal/server/policy_runtime.go because its external parser exited with status 2. (jenkins.console_failures line 299, 2026-08-17T09:05:13)

Evidence

The earliest failure region of the build console:

tty: true
    volumeMounts:
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
  - command:
    - "cat"
    image: "registry.bstein.dev/bstein/quality-tools:sonar8.0.1-trivy0.70.0-db20260422-arm64"
    name: "quality-tools"
    tty: true
    volumeMounts:
    - mountPath: "/home/jenkins/agent"
      name: "workspace-volume"
  - env:
    - name: "JENKINS_SECRET"
      value: "********"
    - name: "JENKINS_TUNNEL"
      value: "jenkins.jenkins.svc.cluster.local:50000"
    - name: "JENKINS_AGENT_NAME"
      value: "soteria-300-rxz9w-35shs-5vq75"

Inferences

The first enforced failure was the SonarQube analysis executed by the Enforce quality gate stage. The missing Node.js executable prevented the TypeScript/JavaScript Sonar analyzer from starting, causing the quality-gate path to exit non-zero before image publication.
The Go parser error occurred earlier and should be investigated after restoring the analysis toolchain, but this bundle does not include the parser's detailed diagnostic or demonstrate that it independently terminated the build.
This is a CI analysis-environment problem rather than a failing application test: the build published no failed test record, and the decisive failure is an unavailable executable in the quality-tools environment.

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: restore_sonarqube_node_toolchain
What it would do: Update and publish the Jenkins quality-tools image or Sonar analysis container so that a Node.js version supported by the installed SonarQube JavaScript/TypeScript analyzer is present on PATH. Re-run the analysis after the image is available to determine whether the separate Go parser error remains.
Evidence that should be required first: The failing scanner output must show that node cannot be executed because it is absent from the analysis container, and the pipeline must identify the SonarQube quality-gate stage as the failed stage.

Links

Failed build: https://ci.bstein.dev/job/soteria/300/
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_4c4f7710910c408bb7d82cfeb27a3ca3). Hermes has no write access to this repository; no files or infrastructure were changed.

Hermes auto-triage classified incident `soteria/300` as **sonarqube_toolchain_missing_node** (confidence 0.91); first failed gate: `sonarqube`. ## Why a human is needed Soteria build 300 failed at its Enforce quality gate stage during SonarQube analysis, not in a published test result. The scanner attempted to start the JavaScript/TypeScript analyzer, ran node -v, and failed because the node executable was missing from the analysis environment. Restoring Node.js in the quality-tools image used by this pipeline is the required fix. The scan also logged an earlier Go parsing failure for internal/server/policy_runtime.go; once the analysis image is repaired, rerun the quality gate and address that file only if the Go parser error still occurs. Ariadne did not authorize automated remediation: `classification_not_supported: 'sonarqube_toolchain_missing_node'`. ## Facts - **jenkins** — Jenkins build soteria #300 finished with result FAILURE after 1674.729 seconds. (`https://ci.bstein.dev/job/soteria/300/`) - **jenkins** — The build reported its first failed pipeline stage as Enforce quality gate. (`jenkins.first_failed_stage`) - **jenkins** — The SonarQube scan logged an error when executing node -v and reported that Node.js was not available during analysis. (`jenkins.console_failures line 299, 2026-08-17T09:05:39`) - **jenkins** — The SonarQube scanner stack trace states that it could not run the node program because it did not exist in the analysis environment. (`jenkins.console_failures line 353: java.io.IOException: Cannot run program "node": error=2, No such file or directory`) - **jenkins** — No structured failed test results were published by the build. (`jenkins.failed_tests=[]`) - **jenkins** — The image build-and-push stage was skipped because an earlier pipeline failure had already occurred. (`jenkins.console_tail`) - **jenkins** — Earlier in the same SonarQube scan, the Go analyzer reported that it could not parse internal/server/policy_runtime.go because its external parser exited with status 2. (`jenkins.console_failures line 299, 2026-08-17T09:05:13`) ## Evidence The earliest failure region of the build console: ``` tty: true volumeMounts: - mountPath: "/home/jenkins/agent" name: "workspace-volume" - command: - "cat" image: "registry.bstein.dev/bstein/quality-tools:sonar8.0.1-trivy0.70.0-db20260422-arm64" name: "quality-tools" tty: true volumeMounts: - mountPath: "/home/jenkins/agent" name: "workspace-volume" - env: - name: "JENKINS_SECRET" value: "********" - name: "JENKINS_TUNNEL" value: "jenkins.jenkins.svc.cluster.local:50000" - name: "JENKINS_AGENT_NAME" value: "soteria-300-rxz9w-35shs-5vq75" ``` ## Inferences - The first enforced failure was the SonarQube analysis executed by the Enforce quality gate stage. The missing Node.js executable prevented the TypeScript/JavaScript Sonar analyzer from starting, causing the quality-gate path to exit non-zero before image publication. - The Go parser error occurred earlier and should be investigated after restoring the analysis toolchain, but this bundle does not include the parser's detailed diagnostic or demonstrate that it independently terminated the build. - This is a CI analysis-environment problem rather than a failing application test: the build published no failed test record, and the decisive failure is an unavailable executable in the quality-tools environment. ## 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: `restore_sonarqube_node_toolchain` - What it would do: Update and publish the Jenkins quality-tools image or Sonar analysis container so that a Node.js version supported by the installed SonarQube JavaScript/TypeScript analyzer is present on PATH. Re-run the analysis after the image is available to determine whether the separate Go parser error remains. - Evidence that should be required first: The failing scanner output must show that node cannot be executed because it is absent from the analysis container, and the pipeline must identify the SonarQube quality-gate stage as the failed stage. ## Links - Failed build: https://ci.bstein.dev/job/soteria/300/ - 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_4c4f7710910c408bb7d82cfeb27a3ca3](https://triage.hermes.bstein.dev/chat?resume=run_4c4f7710910c408bb7d82cfeb27a3ca3)). Hermes has no write access to this repository; no files or infrastructure were changed.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: titan/soteria#12