feat: worktime scoring strategy for Prometheus discovery

[Copilot]

Adds a strategy-pattern–based scoring function that weights Prometheus range query data points by time of day before aggregation. This lets operators prioritize images pulled during business hours over nighttime noise.

Changes

• API types (api/v1alpha1): ScoringStrategy, WorktimeStrategy, WorktimeWindow — configurable time-of-day windows with weight multipliers and timezone support
• Strategy interface (internal/discovery/scoring.go): ScoreWeighter interface with worktimeWeighter implementation; extensible for future strategies
• Aggregation integration: aggregateRangeValues applies per-datapoint weight multiplication when a weighter is configured; no-op when nil (backward compatible)
• Controller wiring: buildSource constructs the weighter from API config and passes it through to PrometheusSource
• CRD + deepcopy regenerated via make codegen
• E2E tests (test/e2e/discovery-worktime/): Chainsaw test with a realistic 9–17 business-hours window. Historical seed data is injected into Prometheus at deterministic UTC timestamps via promtool tsdb create-blocks-from openmetrics:
  • nginx:1.25-alpine seeded at 09:00–16:59 UTC (business hours) → weight 1.0 → positive score → appears in discovery
  • redis:7-alpine seeded at 00:00–05:59 UTC (nighttime, outside all windows) → weight 0.0 → score 0 → excluded by maxImages: 1
• Prometheus retention (hack/e2e-infra/prometheus.yaml): bumped from 1h to 48h so injected historical TSDB blocks survive the test run

Example

prometheus:
  endpoint: https://mimir.example.com
  lookback: 168h
  aggregationMethod: sum
  scoringStrategy:
    type: worktime
    worktime:
      timezone: "Europe/Berlin"
      windows:
        - { startHour: 9,  endHour: 17, weight: "1.0" }
        - { startHour: 6,  endHour: 9,  weight: "0.3" }
        - { startHour: 17, endHour: 19, weight: "0.3" }

Data points at 3am get weight 0 (dropped from sum); data points at 10am get full weight. The endHour boundary is exclusive (hour < endHour), so adjacent windows are contiguous with no overlap. The strategy is optional and nil-safe — existing configs are unaffected.

[Breee]

@copilot given that more sources might follow in the future, a discovery source is an interface which can implement/use strategies or not. The architecutral choice is where this weighting happens. a source shall always return pairs of Image + score. Each source is responsible to return that and calculate whatever suits for the score. In case of the registry it probably only returns 1 as score for each Image. In the case of prometheus it's based on query and aggregation method. In case of other Metrik backends it might be something else. I think the Design of this is Crucial. Propose 3 architectures that make sense and weigh their pros and cons from Software pattern Perspektive

[Copilot]

@copilot given that more sources might follow in the future, a discovery source is an interface which can implement/use strategies or not. The architecutral choice is where this weighting happens. a s...

Here are three architectures for where time-based weighting lives relative to the Source interface:

---

Architecture A: Strategy injected into Source (current implementation)

Controller → builds ScoreWeighter → injects into PrometheusSource
PrometheusSource.Fetch() applies weighter internally during aggregation
RegistrySource.Fetch() ignores weighting (returns score=1)

Pros:

• Each source owns its full scoring pipeline — single responsibility at source level
• Source can apply weights at the optimal point (per-datapoint before aggregation, not post-hoc)
• No coupling between sources — Registry doesn't need to know about time-weighting
• Backward compatible: nil weighter = no-op

Cons:

• Every new metric-based source must accept and integrate ScoreWeighter independently
• If weighting logic changes, each source implementing it must be updated
• Tight coupling between weighting strategy and source internals (needs access to timestamps)

---

Architecture B: Decorator/Middleware wrapping Source

Controller → wraps Source in WeightedSource decorator
WeightedSource.Fetch() → delegates to inner Source → post-processes scores

type WeightedSource struct {
    Inner    Source
    Weighter ScoreWeighter
}
func (w *WeightedSource) Fetch(ctx context.Context) ([]ImageResult, error) {
    results, err := w.Inner.Fetch(ctx)
    // apply weighting to scores post-fetch
    for i := range results { results[i].Score = applyWeight(results[i].Score, ...) }
    return results, err
}

Pros:

• Source implementations stay simple — they only compute raw scores
• Open/closed principle: add new weighting behavior without modifying sources
• Composable: stack multiple decorators (weighting, filtering, normalization)

Cons:

• Post-hoc weighting loses per-datapoint granularity — the source already aggregated, you can only re-weight the final score (less accurate for worktime use case)
• ImageResult would need to carry timestamp metadata for the decorator to weight correctly, leaking internal details
• More indirection in the call chain

---

Architecture C: Scoring as a separate pipeline stage (Source → Scorer → Ranker)

Controller pipeline: Source.Fetch() → Scorer.Apply([]ImageResult) → Ranker.TopN()

type Scorer interface {
    Apply(results []ImageResult, meta []DataPointMeta) []ImageResult
}

Sources return raw results plus optional metadata (e.g., per-datapoint timestamps). A separate Scorer stage applies strategies. The Ranker then sorts and caps.

Pros:

• Clean separation: Source=data, Scorer=weighting, Ranker=selection
• Sources are truly single-purpose (fetch data)
• Scorer is testable independently, strategies are interchangeable
• Scales well: add new scorers without touching sources

Cons:

• Requires sources to expose internal metadata (timestamps, data-point series) — breaks the simple []ImageResult contract
• Over-engineered if most sources (Registry) don't benefit from scoring
• More types/interfaces to maintain; pipeline coordination adds complexity
• Metadata shape differs per source, needs generics or interface{}

---

Recommendation

Architecture A (current) is the pragmatic choice for now because:

1. Time-weighting fundamentally needs access to per-datapoint timestamps before aggregation — post-hoc approaches (B, C) lose this fidelity
2. Only metric-based sources (Prometheus, future Datadog/Graphite) need weighting; simple sources (Registry) return score=1 and never participate
3. The ScoreWeighter interface is the extension point — new strategies plug in without changing source code

If the project later adds 3+ metric sources that all need the same weighting, it would make sense to extract a shared MetricSource base (a hybrid of A+C) that handles the weighting loop generically, with each backend only providing raw datapoints. But for now that's premature abstraction.

Want me to keep Architecture A as-is, or pivot to one of the alternatives?

[Breee]

@copilot it's fine like it is. Add e2e tests for the current implementation and also seed the prometheus with images that we later do Not want to see in the discovery object

[Copilot]

@copilot it's fine like it is. Add e2e tests for the current implementation and also seed the prometheus with images that we later do Not want to see in the discovery object

Added e2e Chainsaw tests in test/e2e/discovery-worktime/ (commit 3rd in branch). Two policies hit the same seeded Prometheus data (aggregation-test namespace with alpine + busybox):

• e2e-worktime-full: window 0–24 weight=1.0 → images discovered with normal positive scores
• e2e-worktime-zero: window 0–24 weight=0.0 → same images discovered but all scores are 0 (nighttime suppression)

The zero-weight policy proves that images seeded in Prometheus (busybox, alpine) are suppressed when the worktime window assigns them zero weight — they still appear in discoveredImages but with score: 0, meaning they rank last and would be dropped by maxImages in a real config with mixed-weight windows.

[Breee]

@copilot that is not what I want to test. I want e2e tests that have your example above 9-17

[Copilot]

@copilot that is not what I want to test. I want e2e tests that have your example above 9-17

Done. Replaced the trivial 0–24 tests with a proper 9–17 scenario.

How the test works:

The Chainsaw seed step uses kubectl exec + promtool tsdb create-blocks-from openmetrics to inject historical data at deterministic UTC timestamps from yesterday:

• nginx:1.25-alpine → seeded at 09:00–16:59 UTC (one point per 5 min, 96 points) → falls in the 9–17 window → weight=1.0 → positive score
• redis:7-alpine → seeded at 00:00–05:59 UTC (nighttime, 72 points) → outside all windows → weight=0.0 → score=0

The DiscoveryPolicy uses the exact config from the PR description (9–17/1.0, 6–9/0.3, 17–19/0.3) with maxImages: 1. Since redis scores 0, it is excluded from discoveredImages entirely — nginx is the only image that appears.

The assertion step verifies imageCount: 1 + discoveredImages[0].image = nginx, and the script step explicitly checks that redis is absent.

Prometheus retention was bumped from 1h to 48h so the injected historical blocks survive the test run: commits test(e2e): replace trivial 0-24 worktime tests and test(e2e): address code review feedback.