v0.4.0

v0.4.0 — Integration tests (dwe test)

This release adds dwe test, a declarative integration-test runner that exercises your project's real deploy pipeline inside a fresh, fully isolated, disposable copy of the project — plus the engine features it's built on.

Highlights

🧪 dwe test — isolated, disposable integration tests

Run your actual deploy pipeline — and any assertions or project commands you declare — against a throwaway copy of the project, without touching the environment you work in.

• dwe test run [scenario…] — one YAML file per scenario in workspace/tests/<name>.yml: service toggles, var overrides, and ordered steps in the same schema deploy.yml uses. Flags: --keep, --timeout, --skip-isolation-check, --parallel N.
• dwe test list — list scenarios with their descriptions.
• dwe test clean — sweep kept or leftover test environments (--dry-run); strictly manifest-driven, never guesses at compose-project names.
• Full isolation — git-aware tree copy, per-run compose project name, automatic host-port remapping, its own .dwe/ state, and manifest-driven teardown (never -v).
• Failure reports — on a failing run, the pipeline log, compose ps, and container logs are captured automatically before teardown.
• --parallel N — run scenarios concurrently behind a compact aggregated live view.
• CI-friendly: exit codes (0 pass / 1 fail / 2 couldn't prepare) and --output json.

🔌 New builtin: http_check

A predicate builtin that asserts an HTTP endpoint returns an expected status (and optional body substring), with retries — usable in deploy.yml, validate.yml, and test scenarios.

✅ Predicate builtins as step-body assertions

Any predicate builtin (file_exists, tcp_reachable, http_check, containers_running, env_keys_present, config_keys_present, executable_in_path, shell) can now be used directly as a step body, where it behaves as an assertion: a false result fails the step. Works in every pipeline; existing configs are unaffected.

⏱ Per-step timeout:

An opt-in wall-clock budget on a single step body, honored across deploy.yml, reset.yml, lifecycle.yml, and test scenarios.

🩺 dwe validate tests + compose isolation scanner

Statically check every scenario (schema, references, whole-phase step resolution) without touching Docker — and surface raw-compose constructs (container_name:, hardcoded host ports, external:/named volumes & networks) that would bypass test isolation.

🐳 docker build.prepull_bases

Optional (default: false) workaround for buildkit fetchers that can't reach LAN/private registries: pre-pulls the external FROM base images a build needs, via a plain daemon-side docker pull. Covers both dwe docker build and dwe docker up; advisory, never a hard failure.

Other changes

• Dependency maintenance: golang.org/x/sync, x/term, x/sys bumped; the docs-site (web/) npm deps scoped as devDependencies.
• Documentation and Russian translations for all of the above.

Upgrade notes

No breaking changes — everything here is additive and opt-in. Existing projects work unchanged; dwe test activates only once you add a workspace/tests/ directory.

Full changelog: v0.3.0...v0.4.0