Quality Gates
Relevant source files
The following files were used as context for generating this wiki page:
Quality Gates in the FLEXT Meltano project represent a set of mandatory automated checks and standards that must be met before code is considered "Enterprise Ready" or eligible for promotion. These gates are enforced through canonical make verbs—specifically check, test, val, and docs—and are integrated into both the local development workflow and the CI/CD pipeline. The primary purpose is to maintain a zero-debt baseline, ensuring 90%+ test coverage, strict type safety, and comprehensive documentation compliance.
Sources: README.md:25-27, tests/README.md:88-100, src/flext_meltano/README.md:58-64
Core Validation Mechanics
The Quality Gate system operates on a hierarchy of validation, ranging from local pre-commit checks to full production-scale end-to-end (E2E) testing. The project follows a "Zero-Tolerance" policy where a bypass that hides a symptom is considered a defect, even if the gate passes.
Make Contract and Verbs
Quality validation is centralized through the make utility, providing a standard interface for developers and CI systems.
| Command | Purpose | Target Metrics |
|---|---|---|
make test | Runs the core test suite (Unit & Integration) | 90% Minimum Coverage |
make check | Executes linting and static analysis (Ruff, MyPy) | Zero errors |
make val | Performs deeper validation and business rule checks | Compliance with enterprise schemas |
make docs | Generates and validates technical documentation | 100% docstring coverage |
Sources: README.md:25-27, AGENTS.md:14-22, tests/README.md:88-100
Validation Logic Flow
The following diagram illustrates the sequence of checks an agent or developer must clear to satisfy the Quality Gates.
The flow ensures that fast, isolated unit tests are validated before moving to resource-intensive integration and E2E scenarios.
Sources: tests/README.md:38-55, tests/README.md:143-157
Automated Testing Gates
The testing infrastructure is the primary mechanism for gate enforcement. It is divided into specific categories with distinct performance and coverage targets.
Test Categories and Thresholds
- Unit Tests: Isolated testing of individual components with a target of 95%+ coverage for core modules. Execution must be < 1 second per test.
- Integration Tests: Validates component interactions and external dependencies (PostgreSQL, Redis). Execution must be < 30 seconds per test.
- End-to-End (E2E) Tests: Full pipeline validation (Go -> Python -> Meltano). These are typically reserved for CI/CD environments.
- Extension Tests: Validates specialized adapters like Oracle OIC and custom business logic.
Sources: tests/README.md:30-60, tests/extensions/README.md:130-137, tests/e2e/README.md:103-109
Coverage Requirements
Coverage is strictly enforced via pyproject.toml and verified during make test. If coverage falls below the threshold, the gate fails loud.
# pyproject.toml configuration for coverage gates
[tool.coverage.report]
fail_under = 25 # Note: Project docs specify 90% as the target for promotion
precision = 2
show_missing = true
Sources: pyproject.toml:144-148, tests/README.md:73-75
Static Analysis and Type Safety
FLEXT Meltano mandates strict type safety as a fundamental quality gate. This is enforced through MyPy and Ruff.
Gate Requirements
- MyPy: Must pass in strict mode with 0 type errors. The configuration includes
check_untyped_defs = trueandstrict_equality = true. - Ruff: Must pass with a comprehensive rule set (
select = [ "ALL" ]), excluding only specific documentation or legacy patterns. - Dependency Validation: Checked via
deptryto ensure all imports are correctly declared inpyproject.toml.
Sources: pyproject.toml:161-180, src/flext_meltano/README.md:66-70, pyproject.toml:343-345
Business Rule Validation
Beyond technical code quality, the project uses a validation layer to ensure configuration and metadata meet enterprise standards. These are tested through FlextMeltanoValidators.
# tests/unit/test_validators.py:168-185
def test_validate_target_plugin_name_too_short(self) -> None:
settings: t.ScalarMapping = {
"name": "target-",
"namespace": "test_ns",
"pip_url": "test",
"executable": "test",
}
result = meltano.validate_plugin_config(settings)
tm.fail(result)
if result.error is not None:
tm.that(
result.error,
has="Target plugin names must be at least 8 characters",
)
The validation gate ensures that component names (Taps/Targets), Meltano project configurations, and DBT transformation metadata follow strictly defined naming and structure conventions.
Sources: tests/unit/test_validators.py:168-185, tests/unit/test_validators.py:73-85
Production Readiness Criteria (E2E)
For final production promotion, a specialized "Production Readiness" gate is executed within the E2E environment.
| Metric | Requirement |
|---|---|
| Response Time | Average < 30 seconds |
| Memory Usage | < 1024 MB |
| Error Rate | < 0.01 (1%) |
| Data Integrity | Score > 0.99 |
| Monitoring Coverage | > 95% |
Sources: tests/e2e/README.md:214-232
Summary
Quality Gates in FLEXT Meltano act as the technical and architectural guardians of the codebase. By combining strict static analysis, high-threshold test coverage requirements, and business rule validation, the project ensures that every commit maintains a production-ready baseline. All agents and developers are bound by the "Zero-Tolerance" and "Fix-Forward-Only" laws, ensuring failures are addressed at the root cause rather than bypassed.
Sources: AGENTS.md:14-22, README.md:40-44