Jekyll2026-09-13T18:24:25+00:00https://bbortt.github.io/snow-white/feed.xmlSnow-WhiteConnect OpenAPI specifications with OpenTelemetry traces to unlock endpoint coverage insights, quality gates, and performance analysis — a ground-truth guardrail for agentic and AI-assisted development. Timon Bortertimon.borter@gmx.chRelease 1.10.0: agentic CLI mode, the skill as an APM package, and Tempo v22026-09-12T00:00:00+00:002026-09-12T00:00:00+00:00https://bbortt.github.io/snow-white/2026/09/12/agentic-mode-and-apm-skill-packageThe upcoming 1.10.0 release is about closing the loop between Snow-White and the coding agents that increasingly write the code it’s supposed to be checking.

snow-white calculate --agentic

The CLI’s calculate command has always been usable in CI, but its output was designed for a human watching a terminal: progress logs, colored checkmarks, a final pass/fail line. Fine for a pipeline log, useless for a coding agent trying to decide what to fix next.

The new --agentic flag replaces all of that with a single line of structured JSON:

snow-white calculate \
  --config-file snow-white.json \
  --agentic

{
  "schemaVersion": "1",
  "status": "FAILED",
  "calculationId": "...",
  "qualityGateConfigName": "default",
  "apiLocation": "http://snow-white.example.com/api/rest/v1/reports/...",
  "initiatedAt": "2026-09-12T08:00:00.000Z",
  "summary": { "apiCount": 12, "failedApiCount": 3, "qualityGateFailureCount": 5 },
  "interfaces": [ ... ]
}

No progress logs to strip out, no ANSI colors to parse around — one JSON object naming exactly which interfaces failed and why. It’s mutually exclusive with --async, since agentic mode needs the finished result to report and async mode returns before one exists. Full shape and an example are documented on the CLI Reference.

This is also the flag the Claude Code skill is built around: instead of scraping a JUnit XML report meant for humans, the skill (or any agent) can invoke --agentic and get a backlog it can act on directly.

The skill becomes an APM package

Speaking of the skill — installing it used to mean copying SKILL.md into your repo by hand. It’s moving to APM (Agent Package Manager), so it can be declared as a dependency and updated like one:

# apm.yml
dependencies:
  apm:
    - bbortt/snow-white/.apm/skills/snow-white#v1.10.0

apm install

.apm/skills/snow-white/ becomes the source of truth in the repository; .claude/skills/snow-white/ stays as a generated, committed copy so Claude Code sessions working inside this repo keep working without the APM CLI installed. Manual copying remains an option if you’d rather not add APM as a dependency — see the Claude Code Skill page for both paths.

Grafana Tempo: migrating to the v2 trace API

A smaller but important fix for anyone using the Grafana Tempo integration introduced back in 1.7.0: openapi-coverage-stream queried Tempo’s trace-by-id endpoint at its original, unversioned path (/api/traces/{traceId}). That was never formally deprecated in Tempo’s docs, so we kept assuming it would keep working — until testing 1.9.0 against a newer Grafana-managed Tempo instance turned up one with no v1 endpoint exposed at all.

1.10.0 moves that query to the explicit /api/v2/traces/{traceId} endpoint, which is what current and newer Grafana Tempo backends actually expect. If you’re running Snow-White against a recent Tempo instance and coverage calculation was silently failing to resolve trace details, this release should fix it — no configuration changes required.

]]>Timon Bortertimon.borter@gmx.chRelease 1.9.0: bring your own tracing backend, cut Kubernetes costs2026-09-05T00:00:00+00:002026-09-05T00:00:00+00:00https://bbortt.github.io/snow-white/2026/09/05/cut-kubernetes-costs-disable-otel-ingestionSnow-White ships with its own OTel Collector, an otel-event-filter-stream deployment, and (by default) an InfluxDB instance to store traces for coverage calculation. That’s convenient for a first install, but it’s redundant weight if your organization already runs a tracing backend that your applications export to — you end up paying for two ingestion pipelines instead of one.

Release 1.9.0 fixes that for operators.

otelCollector.disableIngestion

Set this to true in your Helm values and Snow-White stops deploying its own ingestion path altogether: the OTel Collector’s coverage-trace pipelines, the otel-event-filter-stream Deployment, and the public /v1/traces route are no longer created. Snow-White’s own self-observability (its microservices’ internal telemetry) is unaffected — this only removes the stack that exists to ingest your applications’ traces for coverage analysis.

otelCollector:
  disableIngestion: true

Query Grafana Tempo directly

1.9.0 also lets openapi-coverage-stream read traces straight from an externally operated Grafana Tempo instance instead of Snow-White’s bundled InfluxDB:

snowWhite:
  openapiCoverageStream:
    tempo:
      endpoint: 'https://tempo.example.com'
      token: 'your-bearer-token'

Combine both settings and Snow-White no longer runs its own trace-ingestion pipeline or datastore at all — it just queries the Tempo you’re already operating. Fewer pods, less CPU and memory reserved in the cluster, one less system to keep patched.

One thing Helm can’t infer for you: setting disableIngestion: true does not automatically turn off the bundled InfluxDB subchart. If you’re switching to Tempo, set influxdb2.enabled: false yourself, or you’ll have an InfluxDB StatefulSet running unused.

See the Deployment Guide for the full set of otelCollector and openapiCoverageStream options.

]]>Timon Bortertimon.borter@gmx.ch