Release Notes

What's new in each release.

v0.5.3

Staged bootup order

Items now accept an optional stage property (non-negative integer, defaults to 0) that controls deployment order. Stage N+1 containers don't start until all stage N items are healthy — no more custom entrypoint scripts with wait loops.

items:
  - $ref: ../shared/postgres.yaml
    stage: 0
  - $ref: ../shared/redis.yaml
    stage: 0
  - $ref: ../shared/lago-api.yaml
    stage: 1

Stage 0 boots and becomes healthy, then stage 1 deploys. Works on SERVICE, DATABASE, and BROKER items. Existing definitions are unaffected — items without stage default to stage 0 (all parallel, same as before). Stage numbers are sort keys, not indices — gaps are fine. See the Staged bootup order docs for details.

Build-time {{VAR}} in item fields

{{VAR}} references now resolve at build time in item fields (env values, images, passwords, etc.), not just at runtime in test steps. The resolver builds a merged variable map: config.yaml env entries as baseline, then definition-level variables merged on top.

variables:
  REDIS_PASSWORD: changeme
items:
  - type: DATABASE
    name: my-redis
    database: redis
    dbPassword: '{{REDIS_PASSWORD}}'
  - type: SERVICE
    name: my-server
    port: 3000
    healthCheck: /health
    env:
      - name: REDIS_URL
        value: 'redis://:{{REDIS_PASSWORD}}@my-redis:6379'

Shared fragments referenced via $ref also pick up definition-level variables — fragments stay generic and reusable across definitions. Unresolved {{VAR}} in items is an error. See Build-time vs runtime variables for the full resolution rules.

Other

v0.5.2

Mount files

SERVICE items now support a mountFiles field that mounts local files into the container at a specific path (read-only). This eliminates the need for wrapper Dockerfiles that exist solely to COPY config files, keys, or scripts into an image.

items:
  - type: SERVICE
    name: my-service
    image: my-service:latest
    port: 3000
    healthCheck: /health
    mountFiles:
      - source: ../configs/app.toml
        target: /etc/app/config.toml
      - source: ../scripts/entrypoint.sh
        target: /app/scripts/entrypoint.sh

Each entry has a source (relative path from the definition file) and a target (absolute path inside the container). See the Services docs for details.

Entrypoint override

SERVICE items now support an entrypoint field to override the Docker image's ENTRYPOINT. Combined with mountFiles, this lets you inject custom startup scripts into any off-the-shelf image without a wrapper Dockerfile.

Custom database images

DATABASE items now support an image field for using custom or extended database images (e.g. Postgres with pg_partman). This is mutually exclusive with version — use one or the other.

items:
  - type: DATABASE
    name: lago-postgres
    database: postgres
    image: getlago/postgres-partman:15.0-alpine

Bug fixes

v0.5.1

Broker proxies (AMQP & Kafka)

New Go sidecar proxies that capture message broker traffic for test assertions, the same way the interceptor captures HTTP and the DB proxies capture database queries.

Both proxies forward captured messages to Control Tower for storage and to the test-agent for inline assertion evaluation.

Definition syntax

items:
  - type: BROKER
    name: rabbitmq
    broker: amqp

  - type: BROKER
    name: kafka
    broker: kafka

Broker items support optional image, port, healthCheck, env, and command fields for custom broker configurations. The proxy sidecar is deployed alongside the broker container automatically, and your application services connect through the proxy transparently. See the Brokers docs for the full reference.

Message log pipeline

Captured messages flow through a complete pipeline: broker proxy capture → Control Tower ingestion and storage → test-agent document assembly within step time windows → assertion evaluation against message content and metadata.

The dokkimi dump command now includes message logs in its output for debugging.

Elasticsearch support

Elasticsearch works as a standard SERVICE item with its REST API doubling as both application endpoint and health check:

items:
  - type: SERVICE
    name: elasticsearch
    image: elasticsearch:8.17.0
    port: 9200
    healthCheck: /_cluster/health
    env:
      - name: discovery.type
        value: single-node
      - name: xpack.security.enabled
        value: 'false'

Gzip decompression

The interceptor now detects Content-Encoding: gzip on HTTP responses and decompresses bodies for logging. The original compressed bytes are forwarded to the client unchanged, so application behavior is unaffected while traffic logs show readable content.

Bug fixes & hardening

New test definitions

v0.5.0

Ground-up rearchitecture of the test engine, a new expression language, and loop support across the entire definition format.

Unified root context ($)

All assertion paths, extract paths, and variable references now resolve against a single document root:

This replaces the previous fragmented context where different path prefixes resolved against different objects.

forEach loops

Loops are now supported at every level of a test definition:

Loop items can be an inline array or a variable reference. as/name bindings with an index property enable dynamic variable names in extract keys.

Inline validation (test-agent rewrite)

Assertion validation now runs inline in the Go test-agent against in-memory logs instead of round-tripping through Control Tower's TypeScript service. This eliminated ~8,900 lines of CT code, replaced with ~4,900 lines of focused Go, and cut average test runtime to ~110s by removing HTTP round-trips and DB queries from the hot path.

Assertion engine enhancements

JUnit XML reports & CI integration

Test-agent refactor

Broke apart the monolith Go files into focused, testable modules with ~4,000 lines of new unit test coverage.

Definition resolver & validator

CLI improvements

Docs & landing site

Other

v0.4.2

Bug fixes

New features

Improvements

v0.4.1

Bug fix

Improvements

v0.4.0

MCP server

Dokkimi now ships with a local MCP server, giving LLMs interactive access to the CLI. Tools include run_tests, dump_results, validate_file, get_reference, and more.

Run history & per-project isolation

MCP config tools & run history browsing

Docker-only environments

Removed Kubernetes support — Dokkimi now uses Docker environments exclusively.

VSCode extension updates

Integration with the VSCode Test Explorer. Install locally via scripts/reinstall-ext.sh.

Other

v0.3.7

← CLI Reference