Files
windmill/docs/validation.md
T
Ruben Fiszel dce247c6d2 feat(pipeline): write-audit-publish for materialization data tests (#9911)
* feat(pipeline): write-audit-publish for materialization data tests (EE)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: EE worktree E0583 troubleshooting + duckdb feature check row

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* docs: clarify EE symlink example (absolute target, EE repo layout)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* fix(pipeline): move bootstrap DDL inside guarded WAP transaction

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor(pipeline): move WAP guard SQL builder into EE, OSS keeps placement only

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* chore: bump ee-repo-ref to EE branch rebased on EE main

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* style: reword test comment as current invariant per AGENTS.md

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* chore: bump ee-repo-ref (EE module doc update)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* refactor(pipeline): OSS emits typed materialize plan, EE owns WAP transform

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* test: make rewrite assertion build-aware; refresh oss module doc

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* chore: update ee-repo-ref to 7be0bad1a6d6b5c3a107c0a2cd4bf003c36ec34c

This commit updates the EE repository reference after PR #644 was merged in windmill-ee-private.

Previous ee-repo-ref: 63cabae75329429f647e01083936d70f8197dc9e

New ee-repo-ref: 7be0bad1a6d6b5c3a107c0a2cd4bf003c36ec34c

Automated by sync-ee-ref workflow.

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: windmill-internal-app[bot] <windmill-internal-app[bot]@users.noreply.github.com>
2026-07-04 17:19:49 +02:00

2.7 KiB

Validation Check Matrix

After making changes, run the appropriate checks and fix all errors before considering work done.

Backend: What to Check

What changed Command Notes
Core code (no feature gates) cargo check
Enterprise code (*_ee.rs) cargo check --features enterprise,private Also do EE PR workflow (see docs/enterprise.md)
Enterprise + license-gated code cargo check --features enterprise,private,license When the feature requires a valid license key
Kafka trigger code cargo check --features kafka
DuckDB executor code cargo check -p windmill-worker --features duckdb duckdb_executor.rs (and its #[cfg(test)] tests) only compile with this flag — a plain check/test silently skips them
Native trigger code cargo check --features native_trigger
Parquet code cargo check --features parquet
Multiple gated modules cargo check --features enterprise,parquet Combine only the flags you need
API route changes cargo check Then update openapi.yaml and run npm run generate-backend-client
Database migrations cargo check Test migration applies cleanly with sqlx migrate run

Never use --features all_sqlx_features — it compiles everything and is very slow. Check backend/Cargo.toml [features] to find the right flags.

Never use SQLX_OFFLINE=true — a live database is always available.

After all code changes are done, run ./update_sqlx.sh from backend/ to regenerate the offline query cache.

Frontend: What to Check

When Command Time
During iteration npm run check:fast ~2s
Final PR validation npm run check ~50s
After backend API changes npm run generate-backend-client first

Cross-Cutting Checks

Situation Extra step
Added/modified API endpoints Update backend/windmill-api/openapi.yaml, regenerate client
Modified Flow structures Also update openflow.openapi.yaml
Changed DB schema Update backend/summarized_schema.txt if needed
Enterprise file changes Companion PR in windmill-ee-private (see docs/enterprise.md)

When to Write Tests

  • New utility functions in windmill-common: always add unit tests
  • New API endpoints with complex logic: add integration test
  • Bug fixes for non-obvious bugs: add regression test
  • Pure UI changes: no tests required (rely on type checking)
  • Refactoring: ensure existing tests pass, don't add new ones

When to Check Performance

Run EXPLAIN ANALYZE on new/modified queries when touching:

  • Job queue tables (v2_job, v2_job_completed)
  • Hot-path queries (polling, scheduling)
  • Added/removed indexes