Skip to content

Testing and Release

The alpha repository already includes a baseline test suite and validation workflow.

Current automated checks

  • unit tests under tests/unit/
  • end-to-end bootstrap coverage under tests/e2e/
  • CLI validation through datamuru validate
  • Python 3.11, 3.12, and 3.13 compatibility in GitHub Actions
  • deterministic Ruff 0.15.22 static checks
  • strict mypy checks across the complete datamuru package
  • dependency vulnerability auditing with pip-audit 2.10.1
  • strict MkDocs builds
  • wheel and source-distribution metadata checks

Practical commands

Run the tests:

python -m ruff check datamuru tests
python -m mypy datamuru
python -m pip_audit
python -m pytest -m "not live"
NO_MKDOCS_2_WARNING=1 python -m mkdocs build --strict
python -m build
python -m twine check dist/*

Material for MkDocs 9.7.2 and newer prints an upstream notice about the future MkDocs 2.0 direction. DataMuru pins MkDocs to >=1.6,<2, so the notice is not a failing upgrade requirement. Set NO_MKDOCS_2_WARNING=1 for local and CI documentation builds to keep logs focused on DataMuru warnings and errors.

PowerShell equivalent:

$env:NO_MKDOCS_2_WARNING = "1"
python -m mkdocs build --strict

Run config validation:

python -m datamuru.cli.main validate --config examples/minimal/datamuru.yml

Release hygiene expectation

As the product matures, each release should verify:

  • code behavior
  • documentation accuracy
  • schema alignment
  • example correctness

For a SaaS-grade product, release confidence is as much about trust and clarity as it is about passing code paths.

Live Databricks tests are intentionally not executed from public CI because they require customer-controlled credentials. The configured live suite is read-only: it may inspect connectivity, identity capabilities, Unity Catalog metadata, SCIM listings, and read-only SQL metadata, but it must never call create, update, patch, delete, grant, revoke, apply, or destroy operations. Run it against a controlled non-production workspace.