Testing and Validation β ΒΆ
Use the real commands from the repository. Run them from the repository root.
This repository uses several test and validation types:
Lint and syntax checkscatch style, formatting, and Ansible syntax problems early.Unit testsverify isolated logic.Integration testsverify behavior across modules and runtime boundaries.External testsverify live third-party state such as public registries or services when hermetic checks are insufficient.Combined validationruns the standard main verification flow.Local deploy and E2E validationchecks whether apps and deployment flows work in a realistic local stack.
Code Quality and Automated Checks πΒΆ
Use the following table to choose the right lint, syntax, unit, integration, or combined validation command for your change.
Validation Commands π οΈΒΆ
Category |
Command |
What it does |
When to use it |
|---|---|---|---|
Lint |
|
Runs the main lint checks for the repository. |
Use this when you want a broad lint pass before pushing. |
Syntax |
|
Runs the Ansible syntax validation for |
Use this when you changed Ansible roles, inventories, or playbook-related files. |
Lint tests |
|
Runs the lint test suite inside the development environment. |
Use this when you want CI-like lint validation. |
Unit tests |
|
Runs the unit test suite. |
Use this when you changed Python logic or other isolated code paths. |
Integration tests |
|
Runs the integration test suite. |
Use this when your change affects behavior across modules or runtime boundaries. |
External tests |
|
Runs opt-in tests that depend on live third-party systems such as public registries. |
Use this when you need live external verification. It is intentionally excluded from |
Combined validation |
|
Runs the main combined validation flow without the opt-in external suite. |
Use this whenever a change touches at least one file that is not |
Local Deploy and End-to-End Checks πΒΆ
For the retry-loop policy, use Compose Loop as the SPOT. The table below is a command reference for the supported local deployment paths.
Local Validation Commands π ΒΆ
Use the following table when you need realistic local deployment validation or app-level end-to-end checks.
Category |
Command |
What it does |
When to use it |
|---|---|---|---|
Local deploy |
|
Creates the needed inventory and deploys one or more apps. |
Fresh deploy for a specific app set. |
Local deploy |
|
Reuses an existing |
Fast reuse path. |
Local deploy |
|
Reuses an existing |
Fast reuse path after a state reset. |
Local deploy and E2E |
|
Runs a dedicated local validation flow for one or more apps against the dev stack, cycling the stack and re-initializing the inventory first. |
Baseline and recovery path. |
Full local validation |
|
Builds the broader local deployment flow across apps. |
Broad coverage when you explicitly need it. |
Bundle deploy |
|
Aggregates the role groups from one or more inventories/bundles/ entries into |
One-shot validation of a curated app shape (e.g. |
Bundle redeploy |
|
Same bundle resolution as the bundle deploy, but routes through the reuse path (no down/up, no entity purge). |
Fast iteration loop after a prior bundle deploy. |
Local reset |
|
Recreates the local inventory without deploying apps. |
Use this when your local inventory is broken or you want a clean reset. |
Local cleanup |
|
Deletes local deploy artifacts and cleanup data. |
Use this only when you really want to remove local state. |
Important:
Some local deploy commands are destructive.
Read reset/README.md, purge/README.md, or exec/README.md before using the matching helper.
For act-based workflow checks, see Act Workflow Checks.
After a successful local deploy, run
make network-trust-caand restart your browser.
Suite Selection π―ΒΆ
When exactly one test file changes inside one test family, you MAY scope the run with
INFINITO_TEST_PATTERN.When two or more test files change inside the same test family, you MUST run the matching suite command without
INFINITO_TEST_PATTERN:make test-lint,make test-unit,make test-integration, ormake test-external.When a change touches multiple test families, you MUST run every affected suite.
Testing Standards πΒΆ
For test-type-specific requirements, framework, and creation procedures see: