redhat-performance / cloud-governance / 31114182849
73%

DEFAULT BRANCH: main
Ran
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
31114182849

push

travis-pro

web-flow 
Add Orion regression-detection config (#1020)

* Add Orion regression-detection config

Watches the 6 metrics produced by the metrics rollup job
(cloud-governance-orion-metrics-index): 5 tracked-policy counts plus
an aggregate savings figure. Each metric has both an increase and a
decrease entry, since Orion's direction setting only watches one
direction at a time and real drift (count going up) and a silently
broken policy (count dropping toward zero) are both worth catching.

Filters on account.keyword (not account) - the plain field is
analyzed text and a partial match, which was confirmed to cause
cross-account contamination during testing. No metric uses
type: metadata, since that routes a field to a passive display
column and excludes it from actual regression analysis.

Verified live against real backfilled production data: all 12
entries load and query correctly, and the config detects the same
real regression found during the rollup job's own verification.

* Move config out of Docker/, exclude rollup from ecoeng's policy sweep

Move cg-policy-regressions.yaml from Docker/orion/configs/ to a new
top-level orion-configs/ - Docker/ holds build-time artifacts
(Dockerfiles, entrypoint scripts) elsewhere in this repo, while this
is a runtime config Orion reads when it runs, not something baked
into the image. Grouping it under Docker/ was a category mismatch.

Exclude orion_metrics_rollup from jenkins/tenant/aws/common/run_policies.py's
auto-discovery (shared by the ecoeng, default, and qe tenants). That
script scans cloud_governance/policy/aws/ and runs every file found
there unless explicitly excluded, so adding the rollup module there
caused it to run daily, unintentionally, for every account those
tenants process - confirmed live for one ecoeng account. It writes
to a separate ES cluster from the one this integration targets, so
there's no data contamination, but there's no reason for it to keep
running somewhere it was never meant to.

* Set ... (continued)
Source Files on build 31114182849
Detailed source file information is not available for this build.