bstein/bstein-dev-home
1
0
Fork 0
Code Issues 800 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

[hermes] bstein-dev-home #547: test_metrics_publish_stage_failure #178

New Issue
Open
opened 2026-09-23 22:02:58 +00:00 by hermes-automation · 0 comments
hermes-automation commented 2026-09-23 22:02:58 +00:00
Copy Link

Hermes auto-triage classified incident bstein-dev-home/547 as test_metrics_publish_stage_failure (confidence 0.4); first failed gate: Publish test metrics.

Why a human is needed

Build 547 got all the way through the SonarQube scan, npm install, ESLint, and the full Jest unit-test suite (everything passed) before failing at the 'Publish test metrics' stage; the next stage, 'Build & push backend', was skipped as a direct result, and the Gitea asset-publish step was skipped because the overall build wasn't successful. Since no individual test actually failed, this isn't a code or test regression in the usual sense — something in the step that gathers or publishes test/coverage results (or a quality gate it checks) is erroring out, but the exact command and error text for that stage aren't present in the retained console log (it's truncated right around there) and the OpenSearch log store that would normally fill in that detail was unreachable (connection refused). A maintainer should open the full Jenkins console for build 547 and read the 'Publish test metrics' stage directly to see what actually failed; likely candidates are a missing or misnamed test/coverage report file the stage expects to find, a failed push to a metrics endpoint, or a coverage/quality threshold that got tripped. Separately, and not the apparent cause of this particular failure, the SonarQube step logged a real problem: 'node' isn't available in that scanner's environment, so its JavaScript/TypeScript sensors can't run at all, meaning JS/TS code isn't being analyzed by Sonar even though the pipeline currently tolerates it and moves on.

Ariadne did not authorize automated remediation: human_required.

Facts

  • jenkins — Build bstein-dev-home #547 finished with result FAILURE, running from 21:26:00 to 22:00:03 UTC (2042s). (jenkins.result, jenkins.timestamps)
  • jenkins — Jenkins reports the first failed pipeline stage as 'Publish test metrics'. (jenkins.first_failed_stage)
  • jenkins — No structured failing tests were published for this build; jenkins.failed_tests is empty. (jenkins.failed_tests)
  • jenkins — The later 'Build & push backend' stage was skipped: "Stage 'Build & push backend' skipped due to earlier failure(s)". (jenkins.console_tail)
  • jenkins — The frontend ESLint run and the full Jest unit suite (10 spec files: onboarding-flow, account-dashboard, request-access-flow, auth, home, static-views, ai-view, components, entry-router, mermaid-card, sample) all reported PASS. (jenkins.console_failures[3] (line ~716))
  • jenkins — During the SonarQube scan, the JavaScript analysis sensor errored with "Cannot run program 'node': error=2, No such file or directory"; the sensor nonetheless reported '(done)' and TypeScript analysis ran afterward. (jenkins.console_failures[0]-[1] (lines 333, 369))
  • jenkins — The build agent pod bstein-dev-home-547-bphf9-5bxjf-9bcfx briefly went offline ("seems to be removed or offline (java.lang.InterruptedException)") and came back online on its own before the frontend install/lint/test steps ran. (jenkins.console_failures[3] (line 716))
  • jenkins — The pipeline ended with "ERROR: script returned exit code 1", and the Gitea integration skipped publishing assets because the build was not successful. (jenkins.console_tail)
  • opensearch — OpenSearch log correlation for this incident's time window returned no records; the query itself failed with "Connection refused". (log_evidence.error)
  • jenkins — The retained console text is marked truncated (console_truncated: true), and no excerpt covering the inside of the 'Publish test metrics' stage is present in console_failures or console_tail. (jenkins.console_truncated)

Evidence

The earliest failure region of the build console:

21:30:06.487 INFO  Sensor JaCoCo XML Report Importer [jacoco] (done) | time=9ms
21:30:06.488 INFO  Sensor IaC CloudFormation Sensor [iac]
21:30:07.636 INFO  0 source files to be analyzed
21:30:08.049 INFO  0/0 source files have been analyzed
21:30:08.054 INFO  Sensor IaC CloudFormation Sensor [iac] (done) | time=1567ms
21:30:08.055 INFO  Sensor IaC Kubernetes Sensor [iac]
21:30:08.385 INFO  0 source files to be analyzed
21:30:08.586 INFO  0/0 source files have been analyzed
21:30:08.587 INFO  Sensor IaC Kubernetes Sensor [iac] (done) | time=531ms
21:30:08.587 INFO  Sensor JavaScript analysis [javascript]
21:30:20.432 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.javascrip
... (truncated; the full log is in the linked build)

Inferences

  • The build did not fail because of a broken unit test or lint rule — ESLint and the entire Jest suite passed — so whatever is wrong is specific to the 'Publish test metrics' stage itself, most likely in how it collects or publishes test/coverage artifacts (or a threshold it enforces), not in the t...
  • The brief agent disconnect (InterruptedException) resolved on its own and the build continued normally for many more minutes afterward, so it does not look like the cause of the eventual failure.
  • The SonarQube JavaScript sensor's inability to find 'node' points to the scanner environment missing a Node.js binary; this looks like a real gap in that analysis step (JS/TS code isn't actually being scanned), but it doesn't appear to be what stopped the build, since the scan continued and sever...
  • The specific command or error inside 'Publish test metrics' isn't visible in this evidence bundle: the console excerpt is truncated right around that area, and the OpenSearch log store that would normally provide deeper detail was unreachable. Likely candidates worth checking directly in the Jenk...

Links

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

Hermes auto-triage classified incident `bstein-dev-home/547` as **test_metrics_publish_stage_failure** (confidence 0.4); first failed gate: `Publish test metrics`. ## Why a human is needed Build 547 got all the way through the SonarQube scan, npm install, ESLint, and the full Jest unit-test suite (everything passed) before failing at the 'Publish test metrics' stage; the next stage, 'Build & push backend', was skipped as a direct result, and the Gitea asset-publish step was skipped because the overall build wasn't successful. Since no individual test actually failed, this isn't a code or test regression in the usual sense — something in the step that gathers or publishes test/coverage results (or a quality gate it checks) is erroring out, but the exact command and error text for that stage aren't present in the retained console log (it's truncated right around there) and the OpenSearch log store that would normally fill in that detail was unreachable (connection refused). A maintainer should open the full Jenkins console for build 547 and read the 'Publish test metrics' stage directly to see what actually failed; likely candidates are a missing or misnamed test/coverage report file the stage expects to find, a failed push to a metrics endpoint, or a coverage/quality threshold that got tripped. Separately, and not the apparent cause of this particular failure, the SonarQube step logged a real problem: 'node' isn't available in that scanner's environment, so its JavaScript/TypeScript sensors can't run at all, meaning JS/TS code isn't being analyzed by Sonar even though the pipeline currently tolerates it and moves on. Ariadne did not authorize automated remediation: `human_required`. ## Facts - **jenkins** — Build bstein-dev-home #547 finished with result FAILURE, running from 21:26:00 to 22:00:03 UTC (2042s). (`jenkins.result, jenkins.timestamps`) - **jenkins** — Jenkins reports the first failed pipeline stage as 'Publish test metrics'. (`jenkins.first_failed_stage`) - **jenkins** — No structured failing tests were published for this build; jenkins.failed_tests is empty. (`jenkins.failed_tests`) - **jenkins** — The later 'Build & push backend' stage was skipped: "Stage 'Build & push backend' skipped due to earlier failure(s)". (`jenkins.console_tail`) - **jenkins** — The frontend ESLint run and the full Jest unit suite (10 spec files: onboarding-flow, account-dashboard, request-access-flow, auth, home, static-views, ai-view, components, entry-router, mermaid-card, sample) all reported PASS. (`jenkins.console_failures[3] (line ~716)`) - **jenkins** — During the SonarQube scan, the JavaScript analysis sensor errored with "Cannot run program 'node': error=2, No such file or directory"; the sensor nonetheless reported '(done)' and TypeScript analysis ran afterward. (`jenkins.console_failures[0]-[1] (lines 333, 369)`) - **jenkins** — The build agent pod bstein-dev-home-547-bphf9-5bxjf-9bcfx briefly went offline ("seems to be removed or offline (java.lang.InterruptedException)") and came back online on its own before the frontend install/lint/test steps ran. (`jenkins.console_failures[3] (line 716)`) - **jenkins** — The pipeline ended with "ERROR: script returned exit code 1", and the Gitea integration skipped publishing assets because the build was not successful. (`jenkins.console_tail`) - **opensearch** — OpenSearch log correlation for this incident's time window returned no records; the query itself failed with "Connection refused". (`log_evidence.error`) - **jenkins** — The retained console text is marked truncated (console_truncated: true), and no excerpt covering the inside of the 'Publish test metrics' stage is present in console_failures or console_tail. (`jenkins.console_truncated`) ## Evidence The earliest failure region of the build console: ``` 21:30:06.487 INFO Sensor JaCoCo XML Report Importer [jacoco] (done) | time=9ms 21:30:06.488 INFO Sensor IaC CloudFormation Sensor [iac] 21:30:07.636 INFO 0 source files to be analyzed 21:30:08.049 INFO 0/0 source files have been analyzed 21:30:08.054 INFO Sensor IaC CloudFormation Sensor [iac] (done) | time=1567ms 21:30:08.055 INFO Sensor IaC Kubernetes Sensor [iac] 21:30:08.385 INFO 0 source files to be analyzed 21:30:08.586 INFO 0/0 source files have been analyzed 21:30:08.587 INFO Sensor IaC Kubernetes Sensor [iac] (done) | time=531ms 21:30:08.587 INFO Sensor JavaScript analysis [javascript] 21:30:20.432 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.javascrip ... (truncated; the full log is in the linked build) ``` ## Inferences - The build did not fail because of a broken unit test or lint rule — ESLint and the entire Jest suite passed — so whatever is wrong is specific to the 'Publish test metrics' stage itself, most likely in how it collects or publishes test/coverage artifacts (or a threshold it enforces), not in the t... - The brief agent disconnect (InterruptedException) resolved on its own and the build continued normally for many more minutes afterward, so it does not look like the cause of the eventual failure. - The SonarQube JavaScript sensor's inability to find 'node' points to the scanner environment missing a Node.js binary; this looks like a real gap in that analysis step (JS/TS code isn't actually being scanned), but it doesn't appear to be what stopped the build, since the scan continued and sever... - The specific command or error inside 'Publish test metrics' isn't visible in this evidence bundle: the console excerpt is truncated right around that area, and the OpenSearch log store that would normally provide deeper detail was unreachable. Likely candidates worth checking directly in the Jenk... ## Links - Failed build: https://ci.bstein.dev/job/bstein-dev-home/547/ - 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_b7a51a9d2ea049a2ad41eaadbb38dde2](https://triage.bstein.dev/chat?resume=run_b7a51a9d2ea049a2ad41eaadbb38dde2)). Hermes has no write access to this repository; no files or infrastructure were changed. <!-- hermes-triage job=bstein-dev-home classification=test_metrics_publish_stage_failure incident=bstein-dev-home/547 -->
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
bstein
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: bstein/bstein-dev-home#178
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?