Keep your promanomaly configuration in Git and validate it on every pull request. This prevents broken or overly expensive configs from ever reaching production.
The repository ships a composite GitHub Action (action.yml) that wraps promanomaly validate.
The action runs promanomaly validate with the checks you enable:
- Schema validation (always on) — config parses and matches the pydantic schema.
--estimate-cost(default: on) — statically projects cardinality, TSDB query load, and rough CPU/memory usage. Withstrict, exceedingsafety.max_total_seriesfails the job. Requires no live datasource.--probe(default: off) — executes every query against a live TSDB and fails on empty or errored results.--lint-metadata(default: off) — warns when raw counters are fed to detectors withoutrate()orincrease(). Requires datasource access.
strict (default: true) turns any soft finding into a hard failure.
| Input | Default | Description |
|---|---|---|
config |
required | Path to the config YAML file |
estimate-cost |
true |
Enable static cardinality & cost projection |
probe |
false |
Run live queries against datasource |
lint-metadata |
false |
Enable counter-without-rate linting |
strict |
true |
Fail on any issue |
datasource-url |
from config | Override datasource for probe/lint checks |
python-version |
3.12 |
Python version used by the validator |
name: Validate promanomaly config
on:
pull_request:
paths:
- "promanomaly/**.yaml"
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: esops-dev/promanomaly@main
with:
config: promanomaly/config.yaml
estimate-cost: "true"
strict: "true" - uses: esops-dev/promanomaly@main
with:
config: promanomaly/config.yaml
probe: "true"
lint-metadata: "true"
strict: "true"
datasource-url: https://staging-tsdb.internal/Pin the action to a specific release tag (instead of @main) once you adopt a stable version.
This action pairs perfectly with promanomaly generate-rules:
- Generate a PrometheusRule skeleton from your config.
- Edit the
TODOalert thresholds. - Validate the full config in CI with this action.
- Commit the changes.
The workflow mirrors the one used by promforecast, so teams running both tools use identical CI patterns.